EOS M3 porting [M3] [EOS_M3]

a1ex

Updated QEMU to emulate SD card access on M3. SD1stInit appears to do its job successfully, and the card write protect switch check before StartDiskboot is also recognized.

[ SD1stInit:010f3ff1 ] SetSSCG(12,0)s
[ SD1stInit:010f3ff1 ] HWInit(0)s
SD: CMD0 0x00000000 state 0
SD: No response 0
[ SD1stInit:010f3ff1 ] SWInit(0)s
[ SD1stInit:010f3ff1 ] SetUHSMod(0,1)s
[ SD1stInit:010f3ff1 ] RegPowCF(0)s
[ SD1stInit:010f3ff1 ] CrdPreInit(0)s
SD: CMD0 0x00000000 state 0
SD: No response 0
SD: CMD52 0x80000c08 state 0
SD: No response 0
SD: CMD0 0x00000000 state 0
SD: No response 0
[EOS] trigger int 0xEE
SD: CMD0 0x00000000 state 0
SD: No response 0
[EOS] trigger int 0xEE
SD: CMD8 0x000001aa state 0
SD: Response: 00 00 01 aa state 0
[EOS] trigger int 0xEE
SD: CMD5 0x00000000 state 0
SD: No response 0
SD: CMD55 0x00000000 state 0
SD: Response: 00 40 01 20 state 0
[EOS] trigger int 0xEE
SD: ACMD41 0x50100000
SD: Response: 80 ff ff 00 state 1
[EOS] trigger int 0xEE

I guess the code needs to reach FC37A2E2, where it probably checks the BOOTDISK flag on the SD card image. I'll figure it out later.

@Ant: can you give me a small DISKBOOT.BIN for testing? (something that prints hello world on UART, for example)

Ant

Do you understood how to reliably enter to debug shell?
I was trying to short RX and TX lines - it does not work.

DISKBOOT.BIN

116.83KB

a1ex

The code waits for a '#' on the UART (that is, echo the first character it outputs). It doesn't matter if you output more stuff after that (only the first character is checked).

I guess shorting the two pins during startup should work, and the "loopback" name suggest the same thing...

Ant

Finaly I restored my camera without using file IO functios.
I has generated 64kB array, and then wrote it to flash using small function:

void rescue_me(void)
{
char voltagestr [64];
unsigned int i; 

	sprintf (voltagestr, "Hello world\n\r");			
	( ( void ( * ) ( char* ) ) 0xFC003181 )(voltagestr);	
			
			i = _write_flash(0xFDF20000, &data2k[0], 0x00010000);			

	sprintf (voltagestr, "\n\rResult: %08x\n\r", i);			
	( ( void ( * ) ( char* ) ) 0xFC003181 )(voltagestr);	
			
			*(int*)0xd20b0810  = 0x4d0002;	 // Orange Led = on			
while (1);
}

I called it after fc1ee640. Function fc0f4222 was commented because it generate assert.

Big thanks to a1ex for his help.

P.S. on QEMU write_flash function can not be finished, but erase_flash returns 0.

a1ex

Hurray!

a1ex

Ant
P.S. on QEMU write_flash function can not be finished, but erase_flash returns 0.

The flash emulation is turned off by default. There are two attempts - g3gg0's code in eos.c (I remember he ran into some issues, but back then, what he did was way beyond my understanding on how flash works, so I couldn't debug it), and Antony Pavolv's attempt in digic*.c for A1100 (which is merged in the official QEMU source tree, so it probably works). I should integrate the code from eos.c there to try it, but this is a non-trivial task. And so far I had no real reason to emulate the flash reprogrammig...

Ant

reyalpIf things like focus mode, subject distance and zoom state don't exist as propcases, they will probably need to be faked something like I did for PROPCASE_SHOOTING on g7x.

This is the list of commands that allows to control EF lenses:

 EFLensCom.AFMFSwState
 EFLensCom.ChangeEF2Sync
 EFLensCom.ChangeSync2EF
 EFLensCom.Connect
 EFLensCom.DebugPrint
 EFLensCom.Disconnect
 EFLensCom.DistanceInfo
 EFLensCom.FocusSearchFar
 EFLensCom.FocusSearchNear
 EFLensCom.GetAberrationData
 EFLensCom.GetEFComState
 EFLensCom.GetEFComState
 EFLensCom.GetFNoRange
 EFLensCom.GetFNo
 EFLensCom.GetFocalLength
 EFLensCom.GetFocalLength
 EFLensCom.GetFocusPitch
 EFLensCom.GetID
 EFLensCom.GetIrisSpeedInfo
 EFLensCom.GetLatestGyroData
 EFLensCom.GetLatestGyroData
 EFLensCom.GetLensType
 EFLensCom.GetNewPO
 EFLensCom.GetPO
 EFLensCom.GetiBpDesign
 EFLensCom.IsSafeModeLens
 EFLensCom.LensFirmUpdate
 EFLensCom.LoadAEData
 EFLensCom.LoadiBpManufacture
 EFLensCom.MoveFocusBySync
 EFLensCom.MoveFocus
 EFLensCom.MoveIrisBySync
 EFLensCom.MoveIris
 EFLensCom.MoveIris_FNo
 EFLensCom.OneShotEFStatus
 EFLensCom.PrintCameraInfo
 EFLensCom.PrintDCL1st
 EFLensCom.PrintDCL2nd
 EFLensCom.PrintDCLInit
 EFLensCom.PrintDLC1st
 EFLensCom.PrintDLC2nd
 EFLensCom.PrintDLCInit
 EFLensCom.PrintLib
 EFLensCom.PrintStatus
 EFLensCom.PrintUnitSpec
 EFLensCom.ResetFocusPulse
 EFLensCom.Reset
 EFLensCom.ResumeStatus
 EFLensCom.SendCommand
 EFLensCom.SetError
 EFLensCom.SetFPSetting
 EFLensCom.SetFocusPowerBySync
 EFLensCom.SetFocusSpdPtn
 EFLensCom.SetPFSetting
 EFLensCom.StartOCKick
 EFLensCom.StopOCKick
 EFLensCom.SuspendStatus
 EFLensCom.SuspendStatus
 EFLensCom.SyncComFocusInfo
 EFLensCom.SyncComFocusStatus
 EFLensCom.UpdateStatus
 EFLensTool.Create

reyalp

Ant
This is the list of commands that allows to control EF lenses:

If those work like the names suggests, it seems like most of the focus and av related values should be available. Zoom and the fl_tbl related code might need additional work. So in get_property_case you could do something like

#if CAM_PROPSET == x
switch (id) {
 case PROPCASE_AV:
//some code that calls EFLensCom.GetFNo and stuffs the result into to the return buffer
...

Propcases like AV normally only update in half shoot, so it might be better to just save the in a variable there instead of getting it each time the propcases are red. Setting would need additional consideration.

It would be useful to know if the regular firmware uses these same functions (or something trivially called by them)

The propcase IDs for these "fake" propcases should be outside the normal range used by the camera in your propset.

M3man

Is there an unstable release I can download? What's the status right now?

Ant

M3man

You can find the link in the first post.

M3man

Ant would you say it's safeish to install it on my personal M3? on a scale of 1-10 how safe?

Ant

Fifty-fifty, as usual. 😀
And read the FAQ: http://chdk.wikia.com/wiki/FAQ#Q._Can_CHDK_damage_your_camera.C2.A0.3F

M3man

Huh, I was under the impression that the PS.FI2 was required to get CHDK working, and that file is not present in the zip you attached. What do I do, it's not booting (I'm a total noob if you couldn't tell)

Ant

There is no *.FI2 available at this moment because I am using DISKBOOT.BIN method and special software that makes SDcard bootable.

Read FAQ and Wiki. http://chdk.wikia.com/wiki/Prepare_your_SD_card

Ant

Tried to use FI2 method to run CHDK: camera crashes during startup somewhere after CreateTask_spytask() . Display does not turn on.

ASSERT!! Accelerometer.c Line 1054
Occured Time  2016:08:15 01:00:11
Task ID: 15335455
Task name: Acceleromete4
SP: 0x0069F334
StackDump:
0x00000000
0x00000000
0xFC1F3BBC
0x0000041E
0x00000009
0xFC1F3BBC
0x0000041E
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0xBFE155C5
0x00009CA8
0x0000803C
0x19980218
0xFC1F3AAD
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x00682D5C
0x0000803C
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0x19980218
0xBFE11735
0x19980218
0x19980218
0x19980218
0x19980218
0x00000408
ShootConDump:
0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 
CameraConDump:
12 0f 0f 0f 0f 0f 0f 0f 0f 0f

It looks like first start after closing battery cover, but camera freezes for a few minutes before crash.

reyalp

FWIW, all digic 6 ports so far have unresolved issues with the "firm update" boot. SX280, SX60 and G7X boot but some shooting modes crash, and the orientation sensor freaks out.

Ant

Motion detection seems to be working.
Now I'm trying to adapt "edge overlay" to Digic6.
https://app.assembla.com/spaces/chdk-m3/subversion/commits/16
In live state it works to slow(less than 1 fps). And without edge filter I'm getting strange result:

62ndidiot

Now I'm trying to adapt "edge overlay" to Digic6.
https://app.assembla.com/spaces/chdk-m3/subversion/commits/16
In live state it works to slow(less than 1 fps). And without edge filter I'm getting strange result:

Probably you will need to change the Sobel (calc_edge_overlay) edge detection and average_filter_row code to not use UYVYYY but instead use UYVY. In edgeoverlay.c, I see you have adjusted some dimension (viewport, #of bytes per pixel etc) but you need to modify the code to reference the correct Y values. You can see for example:

       // convolve vert (first Y of next pixel)
            conv2 = *(ptrh1 + x + 1) * ( 1) +
                    *(ptrh1 + x + 3) * ( 2) +
                    *(ptrh1 + x + 4) * ( 1) +

                    *(ptrh3 + x + 1) * (-1) +
                    *(ptrh3 + x + 3) * (-2) +
                    *(ptrh3 + x + 4) * (-1);
            if  (conv2 < 0)     // abs()

I think the code is referencing uYvYYY (bytes 1,3,4,5,7,9) and will need to be changed.
Basically, change to only use odd numbered bytes. 3x3 matrices
X+ 1, 3, 5. You won't have the complication of needing to have differently arranged groups of three in Digic 6

Hardware_Hacker

EOS M3-101a complex test results are below.
(**** Firmware creation completed successfully)

Note 1:- Ant uses a Fixed CHDK version.

Note 2:- H-H uses Variable CHDK version's:-
And also there is other minor version differences.

Note 3:- H-H uses Win-10v586 PE as a "Standard" test platform.
Note 4:- Each Eos-M3 has a "Unique" LibUSB driver.

a/ EOS M3-101a #1 1v5-4660-full Revision 10, original, by Ant. (17-07-2016)
b/ EOS M3-101a #1 1v5-4676-full Revision 14, original, by Ant. (22-07-2016)

The Eos-M3-101a, Camera under test, #1 is also slightly faulty.
The Eos-M3-100d Cameras, #0 & #2 are Ok, but are still UN-ported.
All are tested with a 22mm f2 STM Canon EF-M Lense.
At this stage a, non-chipped, and non-canon EF-* lenses don't work.

The complex test results are attached as a series of screen shots.
Best viewed from top to bottom and left to right.

They are also colour coded:-
Light Gray for some technical details.
Green for stuff that appears to work Ok.
Orange for stuff that appears to not work.
Red for stuff that appears to fail.

Note 5:- I thought build 1v5-4676 wouldn't work, but I decided to test it "As Is".

To Do:- Try to fix some compile errors and some other stuff try again.

i.e. "..failed to get CreateTask args..", "..duplicate name..", "..missing..", etc.

H-H

Continued in next Post #119

Hardware_Hacker

Continued from Post #118

EOS M3-101a complex test results are below.
(**** Firmware creation completed successfully)

Note 1:- Ant uses a Fixed CHDK version.

Note 2:- H-H uses Variable CHDK version's:-
And also there is other minor version differences.

Note 3:- H-H uses Win-10v586 PE as a "Standard" test platform.
Note 4:- Each Eos-M3 has a "Unique" LibUSB driver.

a/ EOS M3-101a #1 1v5-4660-full Revision 10, original, by Ant. (17-07-2016)
b/ EOS M3-101a #1 1v5-4676-full Revision 14, original, by Ant. (22-07-2016)

The Eos-M3-101a, Camera under test, #1 is also slightly faulty.
The Eos-M3-100d Cameras, #0 & #2 are Ok, but are still UN-ported.
All are tested with a 22mm f2 STM Canon EF-M Lense.
At this stage a, non-chipped, and non-canon EF-* lenses don't work.

The complex test results are attached as a series of screen shots.
Best viewed from top to bottom and left to right.

They are also colour coded:-
Light Gray for some technical details.
Green for stuff that appears to work Ok.
Orange for stuff that appears to not work.
Red for stuff that appears to fail.

Note 5:- I thought build 1v5-4676 wouldn't work, but I decided to test it "As Is".

To Do:- Try to fix some compile errors and some other stuff try again.

i.e. "..failed to get CreateTask args..", "..duplicate name..", "..missing..", etc.

H-H

« Previous Page Next Page »