CHIMP - Canon Hack Installation and Management Platform

Canon Hack Installation and Management Platform - a Windows utility for installing/updating CHDK (and more).

Source
Releases (Patch added)

If you encounter a bug:

• Make sure it isn't a known limitation (see below) or issue.
• CHIMP.exe /verbose
• cd %TEMP%\CHIMP
• Locate the relevant log file (should be CHIMP-YYYYMMDD.log)
• Create an issue attaching the log file from the previous step.

Known limitations:

• No special multiple partition handling on Windows 10 Creators Update
• No maximum card size checks. Use at your own risk!

Some people don't like to install java just to run stick, so there's certainly room for a native windows utility. You might also be able to avoid some of the confusion about running it with the correct permission.

Probably obvious, but one thing you should be very cautious about is ensuring the selected SD card is actually an SD card.

IIRC there are a couple cameras which cannot be detected correctly from exif, see http://www.zenoshrdlu.com/stick/sticknfb.html

You might be able to detect the camera by platform id when it's connected to USB.

Thank you for your reply.

Some people don't like to install java just to run stick, so there's certainly room for a native windows utility.

Well, not native per se, since it requires .NET Framework 4.5.2 (I'm not sure why I selected that specific version; 4.5 would probably do).

You might also be able to avoid some of the confusion about running it with the correct permission.

Check.

IIRC there are a couple cameras which cannot be detected correctly from exif, see http://www.zenoshrdlu.com/stick/sticknfb.html

Check, see attachment

Probably obvious, but one thing you should be very cautious about is ensuring the selected SD card is actually an SD card.

Actually, this one is tricky. I can easily verify that the card is SD if it's in the built-in card reader, but not if it's in an external one (at least not easily).

Now, I'm going to need a couple of CHDK questions answered for this utility to be usable (Can you spot the problem with the first couple of screenshots? ) Should I post those here or in separate topic(s)?

Actually, this one is tricky. I can easily verify that the card is SD if it's in the built-in card reader, but not if it's in an external one (at least not easily).

On thing you might do is sanity check the size and existing format, and put up a big warning if it's unusual e.g. 4-64 GB in FAT32 or EXFAT is unlikely to be someones main hard drive at least. Of course there's some overlap, 128 GB cards and SSDs are relatively common.

Now, I'm going to need a couple of CHDK questions answered for this utility to be usable (Can you spot the problem with those first screenshots? ) Should I post those here or in separate topic(s)?

Probably simplest to just keep it in this thread.

On thing you might do is sanity check the size and existing format, and put up a big warning if it's unusual e.g. 4-64 GB in FAT32 or EXFAT is unlikely to be someones main hard drive at least. Of course there's some overlap, 128 GB cards and SSDs are relatively common.

Oh, I thought you were talking about distinguishing between SD/MMC/CF etc.

Internal hard drives are never candidates, since only Removable Media drives are enumerated.

If multiple candidates are present, the user will have to explicitly select one; see screenshot (note the radio buttons in lieu of a combo-box).

As for exFAT, isn't FAT12/FAT16/FAT32 required for autoboot to work? I'm hoping to get rid of the Firmware Update mode wherever possible, which brings me to the first set of questions...

Internal hard drives are never candidates, since only Removable Media drives are enumerated.

I don't know your code would see them, but FWIW internal hard drives can show up as removable drives (e.g. http://www.overclock.net/t/974023/fix-ahci-sata-drives-showing-in-safely-remove-hardware)

As for exFAT, isn't FAT12/FAT16/FAT32 required for autoboot to work?

Yes, current cameras do not boot from exFAT. But 64 GB and larger cards are likely to come formatted exFAT.

So the answer to my riddle from above is that CHDK won't autoboot from a FAT32 card (1st screenshot) on IXUS 870 (2nd screenshot).

I used the ExifTool metadata and camera_list.csv as inputs to build a mapping from Model ID + Firmware Revision to CHDK build prefixes.

My next steps are to determine for each model:

1. whether booting from FAT32 is supported. I believe that if the build includes any SD Card partition options, the answer is no. Which build option should I look for?

2. the ALT button. I found CAM_ALT_BUTTON_NAMES and CAM_ALT_BUTTON_OPTIONS in platform_camera.h, but what if CAM_ADJUSTABLE_ALT_BUTTON is undefined (as in ixus870_sd880)?

3. the autoboot flag. N and N Facebook use the microSD door, which is indicated by KBD_SKIP_READONLY_BIT and SD_DOOR_OVERRIDE in platform_kbd.h. Any other models/flags?

Bonus question:

Is the SD Card tool a module? I'm hoping to remove it whenever possible (i.e., for a bootable single partition).

STICK (and ASSIST) use the following method to detect if the camera supports booting from FAT32:


1. obtain the camera model ID from the photo's EXIF (Canon bump this number up with each new model, so it's in historical sequence) - this number is in the CanonMakerNoteDirectory with an offset of x'10' - see http://www.exiv2.org/tags-canon.html (Ger Vermeulen's page no longer exists)
2. compare it with the number of the first camera to support booting from FAT32 (the A3300) - the first with DRYOS2.3 Release 47 - its ID is 0x2980000


The algorithm to select a drive tries its best to avoid 'hard drives' by checking the removability and size, but as REYALP says, there are problems with 128GB. Both STICK and ASSIST present a dropdown list of drives if there's more than one suitable candidate.

I'm happy to share the Windows code that checks for and does any necessary partitioning (it's in the C DLL's containing native methods that STICK loads if run on a Windows machinep. )

I'm also happy to answer any questions you may have about how STICK works - almost all the people who have problems with STICK are Windows users - having an alternative would reduce the number of emails I get!

Hello, Dave.

It's great to hear from you. Thank you for replying and for being so gracious!

STICK (and ASSIST) use the following method to detect if the camera supports booting from FAT32

I guess that would work, but I'm hoping for a (supposedly) more reliable method of deducing it from the CHDK repo.

The algorithm to select a drive tries its best to avoid 'hard drives' by checking the removability and size, but as REYALP says, there are problems with 128GB.

I'm hoping checking drive sizes could be avoided. I believe that if someone really wants to format or corrupt their hard drive, they will find a way.

I'm happy to share the Windows code that checks for and does any necessary partitioning (it's in the C DLL's containing native methods that STICK loads if run on a Windows machine.)

Yes, please.

Was the code in question distilled from CHDK, taken elsewhere, or written by you? In the latter case, would you agree to my releasing it under a liberal license (with proper attribution, of course)? Since I assumed the former, I tentatively selected GPLv2, but I'm flexible.

Speaking of which, fat32format is also GPL. Since STICK already has JNI, why not add it to the package as well?

Thanks.