Canon 40D

Started by dichterDichter, July 18, 2012, 08:55:06 AM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

LensPainter

Hi Pedro -  and your welcome - de nada (is that right?)

Hope it helps!

Kind regards

Uwe

jplxpto


jplxpto

I think, finally found a buffer of LVRAM.
I had seen the address of a memory dumps I made with the help of ptpcam.
With the help of Alex and his img.py file. I can guess the width and height of the image as well as the pitch.
I intercepted the PRINT key event and did two dumps of RAM starting at address 0x10000000 and a size of 256M.

I followed the instructions described on the following page

http://magiclantern.wikia.com/wiki/VRAM/550D


ipython

run -i img.py

a = readsampled("./VRAM_01.DAT")

b = readsampled("./VRAM_02.DAT")

d = array(a) - array(b)

d[d != 0] = 1

plot(d); show()


After reviewing the chart and repeat the test a few times, I identified the pitch.

guessed pitch = 2916
width = pitch / 2 = 1458
height = 1458 / (3/2) = 972

With the help of graphic and addresses that I found when I did a dump to address 0x1e000.
I suspected that the address 0x1dbc0064 is an address VRAM.

I subtract the address of the beginning of my dump and got the following value:

0x1dbc0064 - 0x10000000 = 0xdbc0064 = 230424676


x = 230424676

gw = 1458
gh = 972
gp = 2916

gx = x + gp * (0)

gs = gp * gh

s = readseg("./VRAM_02.DAT", gx, gs)

imgseq(s, gp)

hex(gx)


In the end I visualized the images generated and to my surprise
I finally had my picture in perfect condition (black and white).
The best picture was the 000-odd.png


MEM(0x1e020 + 0x18) = MEM(0x1E038) = 0x1dbc0064
MEM(0x1e0a0 + 0x14) = MEM(0x1E0B4) = 0x1dbc0064

<conn> w 0x1e000 512
0001e000 00000000 0013a2dc 0013a2b8 00000000 10687248 000002d0 000002d0 000000f0
0001e020 00000000 1071f0d4 000002d0 000002d0 000000f0 00000002 1dbc0064 00000798
0001e040 00000798 00000510 00000798 00000510 00000000 00000000 00000000 00000000
0001e060 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0001e080 00000000 00000000 00484e5c 001ee400 00000001 00000f30 00000a20 00001d40
0001e0a0 00001380 00000000 00000001 00000000 00000000 1dbc0064 1e26f264 1071f0d4
0001e0c0 00000000 00484e5c 001ee400 00000000 00000000 00000f30 00000a20 000009c0
0001e0e0 00000750 00000000 00000000 00000000 00000000 000002d0 000001e0 000002d0
0001e100 00000000 00000018 000002d0 000000d8 0001dc00 00000000 00000000 00000000
0001e120 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0001e140 0080478c 00000000 0001db90 00000000 ff8851e4 00012d6c 00000000 00000000
0001e160 ffca415c 00000000 00000000 00000000 00000000 00000000 00000018 000002d0
0001e180 000000d8 00000000 00000000 1071f0d4 000002d0 000000f0 00000000 00000018
0001e1a0 000002d0 000000d8 00000000 00000000 00000000 00000000 00000000 00000000
0001e1c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0001e1e0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

jplxpto


nexiabass

Wow, really great to see this progress!
Is it possible to extend highiso to 12.800?
What about AF-microadjust?

If this could be added, we could name this cam 45D ^^

a1ex

LV buffer is the one used for LiveView display, it's extremely unlikely to have higher resolution than 720x480.

If you alter the data in the LV buffer, the changes should be visible on the display (that's how magic zoom works).

What you found seems to be a buffer used to decode the images in playback (before downsampling it for display), and probably the zoom operations are based on that buffer. It's not used in LiveView (otherwise 40D would be the first Canon dslr that can record 2K). 5Dc has one too.

Check repo.

Indy

Hi,

good progress Jplxpto !

maybe by enable debug on these functions we can find LVRAM addresses (offsets in firmware in the 1st column) :
  4a0290 [BmpDDev] CreatePhysicalVram (PUB)
4a03b4 [BmpDDev] DeletePhysicalVram (PUB)


in 40d 1.1.1 it seems there are function to monitor the MPU=TX19A
  32fa8 MonOpen
  32fb0 MonClose
  32fbc MonRead
  32fc4 MonReadAndGetData
  32fd8 MonWrite
  32fe4 MonCall
  32fec FA_TestMonRead
  32ffc FA_TestMonCall
  3300c FA_TestMonReadAndWrite
  33130 m_hSemaphoreDataComp
  33148 ../MpuMonitor.c


Indy

jplxpto

Quote from: nexiabass on November 12, 2012, 07:16:31 AM
Wow, really great to see this progress!
Is it possible to extend highiso to 12.800?
What about AF-microadjust?

If this could be added, we could name this cam 45D ^^

Welcome to our forum.

Thank you for your nice words.

Remember, we can add great features in ML but still can not transform an old black & white TV to a color TV with a feature like HD and 3D.

For now, I just think support the features that already exist in other cameras, If I ever get that it will be a big win for me :)

When I reach that goal, I hope to have your help to test the result of my work.

BR

jplxpto

Quote from: Indy on November 12, 2012, 12:04:25 PM
Hi,

good progress Jplxpto !

maybe by enable debug on these functions we can find LVRAM addresses (offsets in firmware in the 1st column) :
  4a0290 [BmpDDev] CreatePhysicalVram (PUB)
4a03b4 [BmpDDev] DeletePhysicalVram (PUB)


in 40d 1.1.1 it seems there are function to monitor the MPU=TX19A
  32fa8 MonOpen
  32fb0 MonClose
  32fbc MonRead
  32fc4 MonReadAndGetData
  32fd8 MonWrite
  32fe4 MonCall
  32fec FA_TestMonRead
  32ffc FA_TestMonCall
  3300c FA_TestMonReadAndWrite
  33130 m_hSemaphoreDataComp
  33148 ../MpuMonitor.c


Indy


Hi, Indy.

I hope you're well.

To be honest I had met some of these stubs 'Mon' but I did not know its purpose.
I still do not know what is in them. I no longer have to availability or knowledge to explore these stubs.
Maybe you are one of the people with the capacity to accomplish this task.

I had already looked at the [BmpDDev] CreatePhysicalVram and [BmpDDev] DeletePhysicalVram but
I did not know how to intercept the calls to these functions.
I think I saw something in your post about the 500D or 550D.

I'll follow your suggestion ...

Thank you.

NSTUB(0xFF8448B4, FA_TestMonCall)
NSTUB(0xFF8446EC, FA_TestMonReadAndWrite)
NSTUB(0xFF8445AC, FA_TestMonRead)
NSTUB(0xFF844528, MonCall)
NSTUB(0xFF844284, MonClose)
NSTUB(0xFF84425C, MonOpen)
NSTUB(0xFF844354, MonReadAndGetData)
NSTUB(0xFF8442AC, MonRead)
NSTUB(0xFF844480, MonWrite)
NSTUB(0xFFB27438, mon)
NSTUB(0xFF843024, mon_funcs_table)



grep -i mon 40d.111.ROMF1.0xFF800000.strings

ffb44014  (Called->MoveFocusLensForPcMon)
ffb44038 Err:MoveFocusLensForPcMon, Unexpected PC_MON_MF_MODE = %d
ffb44074  MoveFocusLensForPcMon LatestStep=%d
ffb46c38 Err:HaveLensError, Mounting MonitorTool
ffb47a28 Err:CalcMovingStepForPcMon, Unexpected Coeff = %d
ffb47a5c Err:CalcMovingStepForPcMon, Result step is over 2bytes

jplxpto

Here is the result of my first analysis to function BmpDDev_CreatePhysicalVram.

NSTUB(0xFFCB02B4, BmpDDev_CreatePhysicalVram);


extern int BmpDDev_CreatePhysicalVram(int *pWidth, int *pHeight, int *pPitch, int **pVRamAddress);

int width;
int height;
int pitch;
int *vRamAddress;

int result;

result = BmpDDev_CreatePhysicalVram(&width, &height, &pitch, &vRamAddres);


result is :
   0 when : The parameters are all valid and was allocated a block of 0x15184 bytes
   3 when :(pWidth == NULL || pHeight == NULL || pPitch == NULL || pVRamAddress == NULL)
   5 when : Could not allocate memory (pVRamAddress != NULL && *pVRamAddress == NULL)

width  is 0x2D0 (720)
height is 0x0F0 (240)
pitch  is 0x2D0 (720)
*pRamAddress is the vram address allocated by DMA a filled with zeros.

block size = 0x15180+4 = 86404 d = 360 * 240 bytes

I think, it takes 4 bits per pixel or 2 pixels per byte...
then the resolution should be: 720 * 240


   313:   608.094 [IMP] CreateVram 665
   330:   684.874 [Graphics] GuiClearImage
   331:   684.933 [IMP] (PUB) SetVramInformation(w:720 h:240) 1291
   332:   684.997 SetImageVramParameter x:0 y:0 w:720 h:240/* Aspect:0*/
   333:   685.032 [IMP] (PUB) SyncroAllClearImagePlayWorkVramWithoutEngine 2644


I will explore the mechanisms of debug, developed by g3gg0 and try to get the list of function parameters.

jplxpto

I think, there is another memory location (temporary?) in memory address 0x1e26f264.

0001e0a0 00001380 00000000 00000001 00000000 00000000 1dbc0064 1e26f264 1071f0d4


Quote from: jplxpto on September 17, 2012, 01:36:51 AM
   698:  3711.532 [GUI] StartPlayMain
   699:  3718.551 [Graphics] CreateSharedBuffer !!!
   700:  3719.198 [IMP] (PUB) SetImageWorkMemory 1:0x1dbc0064, 2:0x1e26f264
   701:  3719.274 [IMP] (PUB) SetImageWorkMaxPixel W:2496,H:1872,0x6af200

   702:  3719.292 [Graphics] GuiGraphicsNormalMode (PUB)


ImageWorkMemory 1: 0x1dbc0064
ImageWorkMemory 2: 0x1e26f264



0x1dbc0064 + 0x6af200 = 0x1e26f264

0x6af200 size (maybe)


Seems I actually found two memory locations that I had seen in the past.
ImageWorkMemory 1 & 2. They are YUV 411. W:2496, H:1872 and size: 0x6af200 (>6,68MB)

jplxpto

Quote from: a1ex on November 12, 2012, 09:44:36 AM
LV buffer is the one used for LiveView display, it's extremely unlikely to have higher resolution than 720x480.

If you alter the data in the LV buffer, the changes should be visible on the display (that's how magic zoom works).

What you found seems to be a buffer used to decode the images in playback (before downsampling it for display), and probably the zoom operations are based on that buffer. It's not used in LiveView (otherwise 40D would be the first Canon dslr that can record 2K). 5Dc has one too.

Check repo.

"otherwise 40D would be the first Canon dslr that can record 2K" ... that would be fantastic, a miracle! :)
Thank you

jplxpto

I found these stubs for testing :


NSTUB(0xFF83EE50, FA_CaptureTestImage)
NSTUB(0xFF8473B4, FA_CreateTestImage)
NSTUB(0xFF83F1C4, FA_DefectsTestImag)
NSTUB(0xFF847538, FA_DeleteTestImage)
NSTUB(0xFF840880, FA_DetectDefTestImage)
NSTUB(0xFF83FF80, FA_FA_ProjectionTestImage)
NSTUB(0xFF840060, FA_FA_ShadingTestImage)
NSTUB(0xFF84037C, FA_ObIntegTestImage)
NSTUB(0xFF840C78, FA_ShadingTestImageForLV)
NSTUB(0xFF83F084, FA_SubtractTestImage)
NSTUB(0xFF8448B4, FA_TestMonCall)
NSTUB(0xFF8446EC, FA_TestMonReadAndWrite)
NSTUB(0xFF8445AC, FA_TestMonRead)
NSTUB(0xFF84144C, FA_VProjectionTestImage)
NSTUB(0xFF845380, FA_YuvDevelopTestImage)

NSTUB(0xFF8841E4, GuiTestOneImage)

NSTUB(0xFFB64954, LVTest)


jplxpto


I checked that there are several functions that use the memory address registered in memory location
MEM(0x1e020 + 0x18) = MEM(0x1E038) = 0x1dbc0064. (SetImageWorkMemory 1)

For example, in the function IMP_PUB_DrawImageToVram the following happens:


FFCA110C : R0=0x1E038
...
FFCA1120 call IMPV_PUB_MakeHDVramFromYuv_FFCA7D48

I think that in this case the address 0x1E038 is the parameter of the function IMPV_PUB_MakeHDVramFromYuv


NSTUB(0xFFCA0EE8, IMP_PUB_DrawImageToVram)
NSTUB(0xFFCA7D48, IMPV_PUB_MakeHDVramFromYuv)

jplxpto

I think that the memory allocated by BmpDDev_CreatePhysicalVram is stored at (*0x5C00)->off_0x4.
You can see that at FF9B9510 (sub_FF9B944C).

Today, I no longer have time to test ... tests are for another day!

nexiabass

Quote from: jplxpto on November 12, 2012, 10:32:42 PM
When I reach that goal, I hope to have your help to test the result of my work.

For sure :)

I can't wait to see this happen to the good old 40D!

jplxpto

Hello people...

I have good news...

As I told you before, I don't have much time to dedicate myself to this project but, 
I have devoted some time to understand code and read some documentation.
I have talked to other ML developers and they have helped me a lot.
They have been fantastic ... I think we have a team motivated, united and well organized.

Yesterday I have dedicated some time to test autofocus patterns (AF POINTS)
I can now choose the focus points.


scaricame

Thanks from an Italian fan for the job that is doing, also I possess a canon 40D is I wait for good news!  ;)

jplxpto

Quote from: scaricame on November 23, 2012, 10:13:54 AM
Thanks from an Italian fan for the job that is doing, also I possess a canon 40D is I wait for good news!  ;)

You're welcome!

tanninety

40D owner here. Been eying the T4i for a while. If I could get video out of this 40D (atleast 480p) I'd be holding off getting the T4i for now.

Thanks for the time that's already been put towards this and the efort that's currently being invested.

And thanks jplxpto!

jplxpto

Quote from: tanninety on November 25, 2012, 12:05:58 AM
40D owner here. Been eying the T4i for a while. If I could get video out of this 40D (atleast 480p) I'd be holding off getting the T4i for now.

Thanks for the time that's already been put towards this and the efort that's currently being invested.

And thanks jplxpto!

The work is advancing slowly ... in the last days were made many changes to the code of ML.
I'm now trying to recover what has been working.
The g3gg0 needed to make changes to the boot process and the camera stopped doing boot.
He is helping me solve this problem.

jplxpto

I have to find STUB PtpPropSetUILock.
The Coutts used to unlock the UI when the PTP is connected. I need to do the same.

40d 111

ffb66f7c %s PtpPropSetUILock [%x][%x]

STUB(0xFFB67014, PtpPropSetUILock__maybe);

https://bitbucket.org/hudson/magic-lantern/commits/f85b386a2d61c369050edf490fa324da17794e40

jplxpto

Quote from: jplxpto on November 12, 2012, 11:48:26 PM
Here is the result of my first analysis to function BmpDDev_CreatePhysicalVram.

NSTUB(0xFFCB02B4, BmpDDev_CreatePhysicalVram);


extern int BmpDDev_CreatePhysicalVram(int *pWidth, int *pHeight, int *pPitch, int **pVRamAddress);

int width;
int height;
int pitch;
int *vRamAddress;

int result;

result = BmpDDev_CreatePhysicalVram(&width, &height, &pitch, &vRamAddres);


result is :
   0 when : The parameters are all valid and was allocated a block of 0x15184 bytes
   3 when :(pWidth == NULL || pHeight == NULL || pPitch == NULL || pVRamAddress == NULL)
   5 when : Could not allocate memory (pVRamAddress != NULL && *pVRamAddress == NULL)

width  is 0x2D0 (720)
height is 0x0F0 (240)
pitch  is 0x2D0 (720)
*pRamAddress is the vram address allocated by DMA a filled with zeros.

block size = 0x15180+4 = 86404 d = 360 * 240 bytes

I think, it takes 4 bits per pixel or 2 pixels per byte...
then the resolution should be: 720 * 240


   313:   608.094 [IMP] CreateVram 665
   330:   684.874 [Graphics] GuiClearImage
   331:   684.933 [IMP] (PUB) SetVramInformation(w:720 h:240) 1291
   332:   684.997 SetImageVramParameter x:0 y:0 w:720 h:240/* Aspect:0*/
   333:   685.032 [IMP] (PUB) SyncroAllClearImagePlayWorkVramWithoutEngine 2644


I will explore the mechanisms of debug, developed by g3gg0 and try to get the list of function parameters.

Quote from: jplxpto on November 13, 2012, 02:02:11 AM
I think that the memory allocated by BmpDDev_CreatePhysicalVram is stored at (*0x5C00)->off_0x4.
You can see that at FF9B9510 (sub_FF9B944C).

Today, I no longer have time to test ... tests are for another day!


MEM(0x5BF8) = 0xff9b943c
MEM(ff9b943c) = 'Vram Instance' (0x6D617256 0x736E4920 0x636E6174 0x00000065)



00005be0 aaaaaa7f bbbbbb7f cccccc7f dddddd7f eeeeee7f ffffff7f ff9b91e4 ff9b943c
00005c00 0065cae4 000002d0 000000f0 00000001 00000001 00000000 006301dc 0062ffcc
00005c20 0065cae4 00671d2c 000002d0 000001e0 00000000 00000000 007c417c 00687104
00005c40 ff9c1918 000ea508 00000007 00000001 00000000 00000000 00000000 00000000
00005c60 ff9c3540 0065bbec 0065bcb0 0065c28c 0065c424 0065c1ec 0065bf0c ff9caf40
00005c80 ff9caf50 ff9caf68 0062e8d8 00000000 ff9ed2bc ffa2f848 ffa913e4 ff9d1368



0065cae0 00000038 ff9b943c 000002d0 000002d0 000000f0 10671da4 000ea52c 00000000
0065cb00 00000000 00000000 000002d0 000000f0 0065cad8 00671d20 00015210 22f586fa
0065cb20 50bf205e 0c2f13f7 407d0aff 12fa6ff5 05f758ff 08f70afa 00df0aed 81f92c25
0065cb40 409fe0ff 00fe3dff 01bc04df 027f0d1f 84fe20fc 017db0e5 08fd08cf 22222222



MEM(0x5BFC) = 0xff9b943c  ; pointer to 'Vram Instance'

MEM(0x5c00) = 0x0065cae4  ; VRAM Address (maybe)
MEM(0x5c04) = 0x000002d0  ; width (720)
MEM(0x5c08) = 0x000000f0  ; height(240)
MEM(0x5c0C) = 0x00000001  ; ???

MEM(0x5c24) = 0x00671d2c  ; VRAM Address (maybe)
MEM(0x5c28) = 0x000002d0  ; width (720)
MEM(0x5c2c) = 0x000001e0  ; height(480)
MEM(0x5c3f) = 0x00000000  ; ???

MEM(0x0065cae4) = 0xff9b943c  ; pointer to 'Vram Instance'
MEM(0x0065cae8) = 0x000002d0  ; width  (720)
MEM(0x0065caec) = 0x000002d0  ; pitch  (720)
MEM(0x0065caf0) = 0x000000f0  ; height (240)
MEM(0x0065caf4) = 0x1065cb5c  ; ???

MEM(0x00671d2c) = 0xff9b943c  ; pointer to 'Vram Instance'
MEM(0x00671d30) = 0x000002d1  ; width  (721) ???
MEM(0x00671d34) = 0x000002d0  ; pitch  (720)
MEM(0x00671d38) = 0x000000f0  ; height (240)
MEM(0x00671d3C) = 0x10671da4  ; ???

size = 0x15180 bytes ( 720 / 2  * 240 )

jplxpto

In search of lost VRAM of 40D111...

MEM(ff9b943c) = 'Vram Instance' (0x6D617256 0x736E4920 0x636E6174 0x00000065)

hexdump -C DUMP_RAM_0x0_0x100000.bin | grep "3c 94 9b ff"

00005bf0  7f ee ee ee 7f ff ff ff  e4 91 9b ff 3c 94 9b ff  |............<...|
000ea4e0  12 00 00 00 02 00 00 00  3c 94 9b ff 01 00 00 00  |........<.......|
000ea530  3c 94 9b ff 01 00 00 00  38 a5 0e 00 38 a5 0e 00  |<.......8...8...|
0065cae0  38 00 00 00 3c 94 9b ff  d0 02 00 00 d0 02 00 00  |8...<...........|
00671d20  10 cb 65 00 58 1d 67 00  38 00 00 00 3c 94 9b ff  |..e.X.g.8...<...|



MEM(0x00005BF0) = 0xFF9B943C

MEM(0x000EA4E8) = 0xFF9B943C (LV VRAM 1) maybe
MEM(0x000EA530) = 0xFF9B943C (LV VRAM 2) maybe

MEM(0x0065CAE4) = 0xFF9B943C (BMP VRAM 1) maybe
MEM(0x00671D2C) = 0xFF9B943C (BMP VRAM 2) maybe

TTS

I've got 2 x 40D, therefore following this development with a smile :-)