Messages

26

Archived porting threads / Re: Canon 6D

« on: April 20, 2015, 12:47:49 AM »

6D.116 - specific

Concerning the 6d.116 port: Thanks maqs & jlgw for the work (even double the amount :-p).

1. It would be nice if both attempts would be merged, jlgw looks a bit more complete right now (including the stub for SetAudioVolumeIn), but maqs has some patches for modules jlgw doesn't have. Here's the wrap:

https://bitbucket.org/JLGW/magic-lantern/branches/compare/6D-116%0Dunified#diff
https://bitbucket.org/Maqs/magic-lantern/branches/compare/6D.116%0Dunified#diff

I left out SetAudioVolumeIn for a reason - it is only used in bitrate-6d.c, which is "disabled" anyway. It cannot be used safely, as all the cache_hack()s would need updating. Consider it a safety measure.

The port is working fine here, but there's about no feedback from testers so far. :-(

2. Personally, I won't use 1.1.6 until it can beep() - can it?

No need for any cache hacking here - just merge in the new sound system, uncomment "#define CONFIG_BEEP" in internals.h and it can beep:
https://bitbucket.org/Maqs/magic-lantern/commits/7dee3c7e7690d6f9e277838a15e9514b35c349a6

The mp3 player works as well, including nice sound effects when turning off the camera while playing. :-)

27

Archived porting threads / Re: Canon 6D

« on: April 04, 2015, 09:13:03 PM »

Hello everybody,

without knowing that JLL is already working on a 6D.116 port, I did a little work myself.

The resulting source code can be found here: https://bitbucket.org/Maqs/magic-lantern/branch/6D.116



Seems to be running so far, but as I am rather a hacker than a user, I could be missing something.  Read this as: please test!

For those of you how want to try the 6D.116 work-in-progress:

• download the 6D.113 nightly as a base
• replace the autoexec.bin file with autoexec.bin
• put the symbol file 6D_116.sym in ML/modules/

Some modules may not work, as they check explicitly for 6D.113.

There may also be bugs. The usual disclaimers apply.

For those of you finding bugs in the 6D.116 image, please send me a private message here or ping me on IRC.

28

Reverse Engineering / NameService - a key (null-terminated string)/value (pointer/int) store

« on: April 07, 2014, 01:21:08 PM »

Hello,

the "NameService" is used by different parts of the firmware. One well-known place for this would be register_function/call.

register_function calls NameService_Lookup to check whether a function is already registered or not. If it's registered, it frees the memory used by the old entry and allocates new memory. At the end, NameService_Register is called to register the new function.
unregister_function calls NameService_Lookup and NameService_Unregister in that order. Besides the calls to the callback function, call(..) only calls NameService_Lookup.

None of the NameService functions deal with allocating or freeing memory for the stored data.

Below, you will find a quick overview over the structures and a few functions I found, some of them untested.

Code: [Select]

struct NameServiceEntry
{
    struct NameServiceEntry *next;
    void *data;
    char Name[];
};

struct NameService
{
    char *aNameService;
    int number_of_entries;
    int semaphore;
    int hash_table_size;
    void *ptr1;   // ptr to ptr1
    void *ptr2;   // ptr to ptr2
    struct NameServiceEntry *hash_table[hash_table_size];
};

// name will be used for the named semaphore created, can be zero if create_semaphore is 0
// if create_semaphore, creates (and uses) a semaphore
struct NameService *NameService_Create(char *name, int hash_table_size, int create_semaphore);

// Free NameService structures (not the data!).
// 0 on success
int NameService_Destroy(struct NameService *n);

// (Over)Write named entry.
// Will overwrite existing entries silently without free()ing it! Use NameService_Lookup first and free data.
// 0 on success
int NameService_Register(struct NameService *n, char *name, void *data);

// Remove named entry.
// 0 on success
int NameService_Unregister(struct NameService *n, char *name);

// Lookup named entry.
// 0 on success
int NameService_Lookup(struct NameService *n, char *name, void **data);     // 0 on success, data points to entry

// Calls callback for each NameService entry. This is useful for freeing all the data.
// 0 on success
int NameService_ForEach(struct NameService *n, void (*callback)(char *name, void *data, void *priv), void *priv);

// 0 if n is a NameService
int NameService_IsInstance(struct NameService *n);

// Internal hash function used by NameService.
int NameService_HashFunction(char *name);

Stubs for 6D.113:

Code: [Select]

FF32CD20 NameService_Create
FF32D304 NameService_Destroy
FF32D114 NameService_Register
FF32D124 NameService_Unregister
FF32D2EC NameService_Lookup
FF32D480 NameService_IsInstance
FF32D554 NameService_ForEach
FF32D5F4 NameService_HashFunction


29

Archived porting threads / Re: Magic Lantern for 6D | Dev kit released

« on: April 02, 2014, 09:17:18 AM »

I'm on 1.1.3 and two of my batteries show this error message when turning the camera on, not sure if its the same as 1.1.4

Same here for 1.1.3 and a cheap AC adapter, but it only appears the first time I turn the camera on after connecting the adapter. I suppose the warning could be easy to suppress, however I don't think suppressing warnings is the best idea, as Canon may have not only financial reasons for showing them. 

30

Modules Development / Re: [6D] GPS / experimental module

« on: March 28, 2014, 06:17:58 PM »

We can read out the time, but it's not that accurate. The hardware interfacing the GPS unit is updating the data every x seconds (as set in the respective property), but does not tell us anything unless we ask for it every time. The original firmware uses a timer to query the property every x seconds. But there is a feature to automatically update the system time from GPS already in the Canon firmware. This may use other props, but I still don't know if it would me more accurate.

There are still some other/unknown fields in the 128-byte long PROP_GPS_INFORMATION property.

31

Modules Development / Re: [6D] GPS / experimental module

« on: March 28, 2014, 08:17:16 AM »

Great you're on it :-) ... I hope we can get some basic gps tracking with that, i.e. save the current position and then be guided back ("car finder mode")!

Fyi, here are some other gps-releated ideas if you didn't see them: http://www.magiclantern.fm/forum/index.php?topic=10663.0 (basically 1. complete geocaching mode and 2. gps power save = lengthen interval on camera idle)

To 2.: I've included a 10 min./30 min. option in the menu. The Canon menu still works (aka does not crash), but does not highlight a value.

As far as I can see, we do not get any directional data, although there are props for something called GPS_COMPAS (sic!), too:

There is

Code: [Select]

#define PROP_GPS_COMPAS 0x80030053
#define PROP_GPS_COMPAS_REQUEST 0x8003005A
#define PROP_GPS_COMPAS_SELECT 0x80040043

PROP_GPS_COMPAS should contain the data (in case it's available on the 6D and once we know how to trigger it), PROP_GPS_COMPAS_REQUEST should be used to request it and PROP_GPS_COMPAS_SELECT is used from some GUI function "SetGPSCompassToStorage". There is no "SetGPSCompassToWinSystem" however, like it is for most other things ("SetSateliteStatusToWinSystem", "SetGPSSelectToWinsystem", ...).

It should be possible to compute directional data for moving cameras though... 

32

Feature Requests / Re: MagicGPS (tm) option for 6d and other gps-enabled cameras

« on: March 28, 2014, 08:06:09 AM »

Anybody has a idea how external USB/Bluetooth GPS connected to a WFT grip should be acceded from ML code ?
I have a WFT-E5 7D grip with a tiny bluetooth dongle connected to it (not the Canon one which is very big and expansive !) and a BT GPS. When all is connected the pictures I take are geotagged and I can see the coordinate when reviewing them but it could be useful to read the location in realtime for the use cases you have mentioned.

At least for the 6D with built-in GPS, there is the possibility to chose an external GPS, too. Therefore I think it uses the same API/props. Does the 7D with WFT-ES have a GPS menu?

Can anybody tell me if modules run on the master or slave DIGiC of the 7D? If they run on the slave (or the master has those property access stubs, too), I could compile my GPS module (http://www.magiclantern.fm/forum/index.php?topic=11209.0) for the 7D.203 and you could try if it's working.

33

Modules Development / [6D] GPS / experimental module (update: 6D.116 support)

« on: March 27, 2014, 02:19:26 PM »

Hello,

I did a bit of GPS reverse engineering, resulting in the following experimental module that makes GPS accessible:



Module: gpsinfo.mo
Source: gpsinfo.zip

The compiled version only works for 6D.113 and 6D.116, but may work with any camera that supports built-in or external GPS. See source code (gpsinfo.c) for more information. I had to redefine both _prop_request_change and _prop_cleanup, as they are not exported and the ML core wrappers available do not work for that purpose. Therefore, the module refuses to run on other cameras/firmware versions.

The more adventurous among you with other cameras may try to point the two functions to the respective functions in your firmware, add is_camera("<your camera>", "<your firmware version>"), rebuild the module and run it at your own risk. Remember: your camera may blow up, come to life or other strange things.

You need to press set on one of the informational entries to update stuff, although the data will only be updated every "GPS refresh interval" internally in the hardware responsible. The GPS related properties I found are in gpsinfo.h.

Best,
Marcus

PS: I just wanted to share what I've done so far. Feel free to improve stuff, ask questions etc.
PSS: The module is now called "gpsinfo.mo", as objects with the same name as core objects will result in modules without any symbols being built.

34

Reverse Engineering / Re: [6D] crypto and networking

« on: March 18, 2014, 04:36:17 PM »

The most interesting thing of course would be to get an api to interface a remote iOS/Android/Win app with ML functions and live view.

An API for that purpose is already present in the firmware itself: PTP/IP. 

(New) wiki page: http://magiclantern.wikia.com/wiki/PTPIP.

The GPhoto devs have already re'ed PTP/IP (http://www.gphoto.org/doc/ptpip.php). As this is just another way of accessing the PTP functionality also available via USB, the ML PTP extensions should work with it as well.

Interfacing PTP/IP works like that:

• Connect to camera port 15740/TCP (control/data connection)
• Send Init_Command_Request:
  
  • 4-byte length (little endian): 8 /* length of header */ + 16 /* length of GUID */ + len(name including "\0\0")
  • 4-byte type (little endian): 0x01 Init_Command_Request
  • 16-byte GUID (looks like "85f16f7f-ea45-32")
  • WCHAR (two-byte characters) for name, last character is NULL
• Read reply to Init_Command_Request (Init_Command_Ack, see GPhoto page)
• Connect to camera port 15740/TCP (event connection)
• Send Init_Event_Request on event connection
  
  • 4-byte length (little endian): 12
  • 4-byte type (little endian): 0x03 Init_Event_Request
  • 4-byte session ID: taken from Init_Command_Ack reply
• Read Init_Event_Ack on event connection
• Use control connection to send normal PTP commands encapsulated as described in Cmd_Request and read their response (Cmd_Response)
• ...

The event connection can somehow be used to retrieve events, but the events need to be enabled and I don't know how to do that. However, 0x9116 (PTP Get Events) may be used as well.

There may be some kind of negotiation first (authentication?). For testing purposes, I just reused the GUID and device name from the connection I captured. It does not take more than a network sniffer (e.g. Wireshark) to spy on the communication between the camera and Canon software, so this is less complicated than reverse engineering the internals of the camera. Maybe somebody with basic knowledge about a programming/scripting language with networking capabilities can give it a try. I used Perl for my experiments and could provide some basic PTP/IP module to any volunteers. It would be nice to have the whole process documented in the wiki.

Best,
Marcus

PS: Does anybody happen to know if those WFT transmitters implement PTP/IP, too?

Edit: wiki page

35

Reverse Engineering / [6D] crypto and networking

« on: March 18, 2014, 02:20:00 PM »

Hello,

I've just created a wiki page for some reverse engineering done for the Canon EOS 6D at http://magiclantern.wikia.com/wiki/6D.

It contains some stuff I found out about a few month ago:

1. Networking

The same functions may or may not exist on the EOS 70D, which also has built in WiFi, and perhaps future cameras, but I think it's likely.

There's also IPv6 support, FTP functionality, DHCP, PTP over IP, ... and TLS hidden in the firmware.

2. Crypto

HMAC-SHA1, together with the networking functionality, could be used to implement OAuth and write a flickr/dropbox/... uploader.

Contributions are welcome!

Best,
Marcus