Documentation for starting a CHDK port

mweerden

194

Documentation for starting a CHDK port

« on: 05 / May / 2009, 00:07:58 »

Advertisements

Hi all,

As I have previously indicated on the CHDK IRC channel, I have been planning to write some documentation on porting for "newbies". My experience in porting the IXUS 870 has been a bit frustrating at times because I hardly had a clue about what I was doing. For a someone new to the CHDK it is hard to get the big picture on how the CHDK works and figure out how to find certain information.

My attempt: http://www.mweerden.net/chdk_porting.html

My intention is to get this documentation (or parts thereof) into the wiki so it can be updated by whoever wants to. No doubt that I have made some mistakes or omissions.

Let me know what you think.

Logged

reyalp

14120

Re: Documentation for starting a CHDK port

« Reply #1 on: 05 / May / 2009, 00:45:31 »

Very nice.

The modification for the jogdial task is to support disabling it. For example, so the jogdial isn't active in alt mode.

You might also want to note that diskboot is only loaded from fat16/fat12

When discussing stubs_entry*, it's probably a good idea to link http://chdk.wikia.com/wiki/Signature_finder

As far as creating ports from a base, my personal preference is starting from scratch, rather than copying a tree and then "fixing" it. The reason is that you know each part is done, rather than having to sort out what's fixed and what's not. It also makes you think about the things you don't understand. My approach was basically to work through the files in the reference tree one at a time, and for each one create a corresponding file in the new port tree. In some cases you can just copy a file or a large chunk without changes, but you still ensure you've looked at each part. This method also helps if there isn't a single good reference to start from, which leads to the next topic:

What should your reference port be ? The ideal reference would be
1) a similar camera
2) a stable, mature port.
3) a recent port (because better ways of doing things, like dryos task hooking, have been discovered but not backported)
4) a well documented port
In reality, you are unlikely to find all of these together so you will probably find yourself flipping between two or three different ports for different things.

Logged

Don't forget what the H stands for.

mweerden

194

Re: Documentation for starting a CHDK port

« Reply #2 on: 05 / May / 2009, 12:22:14 »

Thanks for the comments, reyalp.

Quote from: reyalp on 05 / May / 2009, 00:45:31

The modification for the jogdial task is to support disabling it. For example, so the jogdial isn't active in alt mode.

Hmmm.. I somehow totally missed that.

Quote

As far as creating ports from a base, my personal preference is starting from scratch, rather than copying a tree and then "fixing" it. The reason is that you know each part is done, rather than having to sort out what's fixed and what's not. It also makes you think about the things you don't understand. My approach was basically to work through the files in the reference tree one at a time, and for each one create a corresponding file in the new port tree. In some cases you can just copy a file or a large chunk without changes, but you still ensure you've looked at each part. This method also helps if there isn't a single good reference to start from, [...]

I essentially followed the same approach you did even though I did start with a copy. If you totally start from scratch and are completely unfamiliar with CHDK (code base) it just adds another needless hurdle in my opinion. You could say that people should first get familiar with the code before starting the port, but I suspect that isn't realistic.

If there is no reference you can start from, then I think you've got bigger problems to worry about.

Quote

which leads to the next topic:

What should your reference port be ? The ideal reference would be
1) a similar camera
2) a stable, mature port.
3) a recent port (because better ways of doing things, like dryos task hooking, have been discovered but not backported)
4) a well documented port
In reality, you are unlikely to find all of these together so you will probably find yourself flipping between two or three different ports for different things.

This is a bit of a problem for someone who is new, I think. Asking one of you experts for the best reference is probably the most practical.

Logged

Microfunguy

4037

Re: Documentation for starting a CHDK port

« Reply #3 on: 06 / May / 2009, 05:23:06 »

Quote from: reyalp on 05 / May / 2009, 00:45:31

The modification for the jogdial task is to support disabling it. For example, so the jogdial isn't active in alt mode.

This is not a question about documentation but rather the above-quoted topic.

I have tried to add jog-dial code to another camera.
taskSuspend and taskresume are already in stubs_entry.S
I manually added taskNameToId and printf (with NSTUB).
These (for example _taskSuspend) are all declared in lolevel.h.
There are no wrapper functions (such as taskSuspend() ) in \generic\wrappers.c.
Nevertheless, similar code for cameras such as the ixus65 compiles without problem.

When I compile my version, I first get 'implicit declarations' of those functions and then 'undefined reference'.

Any idea why ?

(I am sure EWAVR knows the answer but he has been unavailable for some days).

David

Logged

hiker_jon

284

Re: Documentation for starting a CHDK port

« Reply #4 on: 06 / May / 2009, 12:24:05 »

Thanks mweerden!

I have been put off from attempting a port (and from buying a camera that has not been ported) because I felt the porting process was impossibly complex. Your guide helps a lot in making it seem possible.

One question: do you have IDA or have you used the GPL tools?

One suggestion: try to minimize the number of links. One huge problem with CHDK documentation is that you have to follow link after link to get the whole picture. Sometimes the links get changed and no longer contain the relevant information or the information gets buried in a long article.

Thanks again.

Logged

mweerden

194

Re: Documentation for starting a CHDK port

« Reply #5 on: 06 / May / 2009, 13:18:08 »

Quote from: Microfunguy on 06 / May / 2009, 05:23:06

There are no wrapper functions (such as taskSuspend() ) in \generic\wrappers.c.
Nevertheless, similar code for cameras such as the ixus65 compiles without problem.

When I compile my version, I first get 'implicit declarations' of those functions and then 'undefined reference'.

I've taken a quick look and it appears that the ixus60 and ixus65 ports have a different stubs_asm.h, where NSTUB(Func,addr) not only defines _Func but also Func. I don't know why this is the case, but I would suggest not doing this. Instead, either replace the uses of Func by _Func or, which seems nicer, add an implementation of Func that calls _Func to your wrappers.c.

The implicit declarations should be because you didn't include include/lolevel.h.

B.t.w.: instead of using NSTUB for manual additions, you can better use NHSTUB. Just to be safe in case a new version of the automatic detection does find these functions.

Quote from: hiker_jon on 06 / May / 2009, 12:24:05

I have been put off from attempting a port (and from buying a camera that has not been ported) because I felt the porting process was impossibly complex. Your guide helps a lot in making it seem possible.

This is great to hear, thanks.

Quote

One question: do you have IDA or have you used the GPL tools?

I've used IDA, which seems to be a good choice. Haven't had any experience with the GPL tools, though. I've heard that IDA also runs using Wine, in case you don't have Windows. (I've tried it myself in the past, but it kept crashing my window manager.)

Quote

One suggestion: try to minimize the number of links. One huge problem with CHDK documentation is that you have to follow link after link to get the whole picture. Sometimes the links get changed and no longer contain the relevant information or the information gets buried in a long article.

Although I acknowledge this problem, I don't think the solution is making one big page. The reason that it's a problem is that there doesn't seem to be enough motivation to keep it all nice and organised. And there isn't anyone you can blame (except perhaps the community as a whole, but they are probably all people who just contribute what they can in their free time). The only real solution I see is someone who steps up and takes up the responsibility of organising the information.

Logged

Microfunguy

4037

Re: Documentation for starting a CHDK port

« Reply #6 on: 06 / May / 2009, 14:10:20 »

Quote from: mweerden on 06 / May / 2009, 13:18:08

it appears that the ixus60 and ixus65 ports have a different stubs_asm.h

That compiles fine, thanks.

David

Logged

hiker_jon

284

Re: Documentation for starting a CHDK port

« Reply #7 on: 08 / May / 2009, 17:01:33 »

Not being a porter (Is that a word?) I have no clue if this is possible, but maybe someone can answer these questions:

I remember that someone commented (maybe on the SX10 porting thread?) that Canon seems to be swamping CHDK with new firmware versions.

This causes me to wonder if it might be easier to port a second firmware version if one has already been ported? Perhaps some simple searches and comparisons of the firmware dumps might be all that is needed?
It would be great to get more people involved in the porting, i.e. people that can't do assembly work, but could do comparisons and searches on firmware dumps.

Jon

Logged

mweerden

194

Re: Documentation for starting a CHDK port

« Reply #8 on: 08 / May / 2009, 21:43:27 »

Quote from: hiker_jon on 08 / May / 2009, 17:01:33

...porter (Is that a word?)...

It is, but you might not find it with its intended meaning in a dictionary.

Quote

I remember that someone commented (maybe on the SX10 porting thread?) that Canon seems to be swamping CHDK with new firmware versions.

I doubt Canon would spend time on such things. It would seriously surprise me if doing that makes any sense (business wise).

Quote

This causes me to wonder if it might be easier to port a second firmware version if one has already been ported? Perhaps some simple searches and comparisons of the firmware dumps might be all that is needed?
It would be great to get more people involved in the porting, i.e. people that can't do assembly work, but could do comparisons and searches on firmware dumps.

It is easier (or should be) as we're talking about less files and files that typically are very similar to the ones for other firmware versions. If the original port has documentation with respect to the origins of certain code/values, I'd suspect that people with less experience should be able to do the required work (which is indeed mostly searches and comparisons). The hardest part is probably debugging the port when it doesn't work straightaway, but this can be mostly avoided by being thorough in comparing.

To stimulate this, I think it would be nice if someone just tried it (probably guided by more experienced porters) and document that process. It is probably not so easy for the more experienced to realise what the difficult things are for less experienced people.

Logged

reyalp

14120

Re: Documentation for starting a CHDK port

« Reply #9 on: 09 / May / 2009, 00:26:15 »

Quote from: hiker_jon on 08 / May / 2009, 17:01:33

Not being a porter (Is that a word?) I have no clue if this is possible, but maybe someone can answer these questions:

mmmm porter

Quote

I remember that someone commented (maybe on the SX10 porting thread?) that Canon seems to be swamping CHDK with new firmware versions.

If you mean canon is putting out new firmwares to thwart CHDK, this is silly. If what you mean is that there's a lot of variants and it's hard for CHDK to keep up with them, this is certainly true.

Quote

This causes me to wonder if it might be easier to port a second firmware version if one has already been ported? Perhaps some simple searches and comparisons of the firmware dumps might be all that is needed?
It would be great to get more people involved in the porting, i.e. people that can't do assembly work, but could do comparisons and searches on firmware dumps.

In many cases, it will only be addresses that changed, and those are changed by a small number of easily obtainable offsets. In theory, you should be able to automatically convert the original port to any variants like this, but in practice setting up the tools to support this would be a a lot of work.

Logged

Don't forget what the H stands for.