supplierdeeply

SX280 / 275 / 270 porting

  • 294 Replies
  • 45940 Views
*

Offline srsa_4c

  • ******
  • 3171
SX280 / 275 / 270 porting
« on: 31 / May / 2014, 17:14:41 »
Advertisements
The port is now part of the official CHDK source.
It's currently designated as 'prealpha', due to several unimplemented CHDK features.

Current, CHDK 1.5 based binary release is in this post (for 102b, 102c, 102d).

Cameras running older firmware versions need to be upgraded to the official 1.0.2.0 (aka 102b) firmware. Even though the firmware is the same, each model needs its own firmware upgrade file: sx270, sx280

Limitations:
  • Many frame buffer based functions are unavailable. That's approximately the following list: histogram, zebra, edge overlay, (parts of) auto iso, motion detection, PTP live view.
  • CHDK overlay (OSD, menu) draws slowly. The default font is tiny, bigger RBF fonts are selectable for the menu.
  • Certain Canon graphic elements make the whole CHDK overlay blink. For example: blinking battery icon, scrolling images in playback mode.
  • Movie mode features and remote shooting (filewritetask) are not available.
  • Rebooting from script is not working.


Heavily modified original text follows.

First test release for the 102b firmware revision (this is the 1.0.2.0 official Canon firmware).
It has a simple version check, if that fails, the camera will go into infinite loop and the battery has to be removed.

Warning: as a test release, it might be unstable.
Known problems:
- CHDK display is not erased properly. To clear the screen, enter and exit the Canon menu or use the "control dial"/jogdial in playback mode to step to another picture. This is annoying, I know. Prealpha2 uses a newer method which is also annoying, but differently.
- The jogdial has no CHDK function. The reason is that there is no jogdial task in firmware, a new control method will have to be found. Fixed in prealpha2.
- No frame buffer related CHDK functions work - the pixel format is different, support for that will have to be added. The (probably incomplete) list of unavailable functions: histogram, zebra, edge overlay, auto iso, motion detection, PTP live view.
- The camera will always start in playback mode. Prealpha3 can now start in rec mode.
- Some colors will look differently than intended, the previously black 0xff color is now pink. Most color issues are fixed in prealpha3 (except the non-existent transparent color and color bleeding caused by YUV).
- Most modules are not aware of the bigger resolution.
- The default text size on OSD is tiny but readable. The OSD editor can be used to increase the size of OSD elements, the menu can be made better with loadable fonts.
- Drawing of the CHDK overlay is slow.
- 'F Number', 'Exposure Time' is bad in DNGs (in exiftool output) Fixed by using native modules since prealpha3.
- ubtest reports
'uBASIC:206 Unk key'
after 'done', file is OK...
fixed in prealpha10
- Movie mode and remote shooting (filewritetask) is not supported at this stage.
- DNG files have all their black borders. Borders corrected in prealpha3.
- Messing with the CHDK ND filter control may crash the camera - all cameras with unofficial ND have this problem.
- Subject distance override is completely untested.
- The CHDK GUI is unusable (distorted, falls apart) when using the analog video out connector. Fixed in prealpha3.
- Overrides are not effective in high speed burst mode.
- Edge overlay re-enables itself randomly (the module is not included because it wouldn't work)
- The reboot() script command is not working.

The benchmark is working, please post your card speed results if you have fast UHS cards.
Note that the test release only supports FAT32 or FAT16 cards.

To load this test release, you need to make the SD card bootable.

Source is here, this toolchain can be used to build it. Modules are not currently built, the included modules were compiled for "regular" CHDK (with the gcc library routines included - changeset 3241 reversed). Modules now build correctly. Compilation was tested with the 32-bit version of the above toolchain (Linux and Win32). Newer source repo is here (changelog).

For generic DIGIC 6 related development talk, this thread is probably more suitable.

edit:
tv-out issue added
edit2:
more issues added
edit3:
more issues, link to newer release
edit4:
another release, issues changed

edit5:
first release removed (I don't think the 67 is the real download count, some people have trouble downloading attachments and re-try many times).
chdk_sx280_sx275_sx270_102b_test1.zip (656.69 kB - downloaded 67 times.)

edit7:
prealpha5
edit9:
more issues
« Last Edit: 12 / November / 2016, 06:31:03 by srsa_4c »

Re: SX280 / 275 / 270 porting
« Reply #1 on: 17 / June / 2014, 19:51:17 »
Hi,

I bought a sx270hs a few days ago. I'm very interested in the port, but it seems Canon shipped it with firmware version 102c (1.0.2.0) so I'm unable to test this build. Is it possible to downgrade somehow?

Re: SX280 / 275 / 270 porting
« Reply #2 on: 17 / June / 2014, 23:09:18 »
I bought a sx270hs a few days ago. I'm very interested in the port, but it seems Canon shipped it with firmware version 102c (1.0.2.0) so I'm unable to test this build. Is it possible to downgrade somehow?
There is no way to downgrade.  In fact,  Canon seldom even allows you to upgrade when they produce a new rev of their firmware.

However, it's not all bad news.  Sometimes two firmware versions can use the same CHDK port - but almost always only if they have sequential revision numbers (like yours).   And if not, it's pretty easy these days for someone to produce a new port once the first one for a camera model is finished.

What is needed is a firmware dump.  Either to check and see if the versions are compatible or to be used in producing a new port.  If you feel up to taking the first step, here's the instructions : http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper .  Before you start though,  you might want to wait and see if srsa_4c posts any caveats.

*

Offline srsa_4c

  • ******
  • 3171
Re: SX280 / 275 / 270 porting
« Reply #3 on: 18 / June / 2014, 11:13:27 »
And if not, it's pretty easy these days for someone to produce a new port once the first one for a camera model is finished.
... unless we're talking about a DIGIC 6 camera. No sigfinder, no code_gen, no CHDK_PT.

Quote
What is needed is a firmware dump.  Either to check and see if the versions are compatible or to be used in producing a new port.  If you feel up to taking the first step, here's the instructions : http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper .
+1


Re: SX280 / 275 / 270 porting
« Reply #4 on: 19 / June / 2014, 08:06:28 »
Would be interesting if the latest firmware version is even better than the version which can be downloaded from Canon.
« Last Edit: 19 / June / 2014, 08:09:57 by Plenz »

Re: SX280 / 275 / 270 porting
« Reply #5 on: 19 / June / 2014, 08:24:18 »
Would be interesting if the latest firmware version is even better than the version which can be downloaded from Canon.
CHDK is not firmware.  It does not make any permanent changes to your camera.  The firmware version provided by Canon is the only firmware on the camera.    CHDK loads into camera RAM memory and adds or modifies the Canon firmware functionality.  It's gone when the power is turned off and has to be reloaded every time.

Re: SX280 / 275 / 270 porting
« Reply #6 on: 20 / June / 2014, 11:52:20 »
Hi guys, I've posted on the firmware dump forum: http://chdk.setepontos.com/index.php?topic=11610.0

Also got my hands dirty with the svn repo, but I'm not sure how to compile it yet. Is there a guide somewhere?

*

Offline srsa_4c

  • ******
  • 3171
Re: SX280 / 275 / 270 porting
« Reply #7 on: 20 / June / 2014, 14:40:39 »
Hi guys, I've posted on the firmware dump forum: http://chdk.setepontos.com/index.php?topic=11610.0
Thanks for the dump!
Unfortunately, there are significant differences to 1.02b, so porting will be needed.

Quote
Also got my hands dirty with the svn repo, but I'm not sure how to compile it yet. Is there a guide somewhere?
That will be the least of your problems for now, but here's how:
Install the gcc 4.8 based toolchain from here: https://launchpad.net/gcc-arm-embedded
The directory containing arm-none-eabi-gcc has to be in PATH.
You'll also need other GNU utilities (make, ...)
From the svn root dir,
Code: [Select]
make fir PLATFORM=sx280hs PLATFORMSUB=102cwill build CHDK (once you have an appropriate 102c port)
it's a good practice to make clean before re-building
Code: [Select]
make clean PLATFORM=sx280hs PLATFORMSUB=102cYou may want to (re-)read my first post above for the current state of the port.

I have put a temporary version check into loader/sx280hs/main.c, that will need to be modified too as it only expects 102b.

If you'd like to help, you can start with adjusting the addresses found in platform/sx280hs/sub/102b/stubs_entry_2.S and stubs_min.S to point to the right place in the 102c dump. You'll find odd (thumb instruction set) and even (arm instruction set) addresses, make sure you preserve their least significant bit.
You may want to try
http://chdk.wikia.com/wiki/User:Srsa_4c/GPL:disassemblev7.pl
on the 102b and 102c dumps, and use the resulting (not perfect) disassembly listings to locate the needed functions and firmware variable addresses for the 102c firmware.
Once this step is complete, all assembly parts found in platform/sx280hs/sub/102b/ files (such as boot.c, capt_seq.c) will have to be corrected to use the 102c addresses. Of course, you'll need to work on the platform/sx280hs/sub/102c directory (start with a copy of the 102b files).

I'm using Linux, setting up a build environment may be harder on other OSes.


Re: SX280 / 275 / 270 porting
« Reply #8 on: 20 / June / 2014, 15:53:38 »
Hi, I'm using Linux aswell and I'm somewhat familiar with embedded systems (did some hobby projects on Atmel microcontrollers and Raspberry Pis)

I've tried to run the dissasembly script you pointed me to, but it seems it expects arm-elf-obj{dump,copy}
Can I use arm-none-eabi-obj{dump,copy} instead or do I need a different toolchain?

*

Offline srsa_4c

  • ******
  • 3171
Re: SX280 / 275 / 270 porting
« Reply #9 on: 20 / June / 2014, 15:58:22 »
Hi, I'm using Linux aswell and I'm somewhat familiar with embedded systems (did some hobby projects on Atmel microcontrollers and Raspberry Pis)
That's good :)

Quote
I've tried to run the dissasembly script you pointed me to, but it seems it expects arm-elf-obj{dump,copy}
Can I use arm-none-eabi-obj{dump,copy} instead
Yes, just edit the script.

 

Related Topics