SX280 HS 101B Dump - I am truly willing to help test if someone develops

Hi,

I have got the dump of this camera's (SX280 HS) firmware. It is 101B according to CameraVersion 1.3.

I would really appreciate it of some developer could port CHDK to this camera. I have been told and read that testing is not just getting an almost ready CHDK build but requires going through a lot of crashes, reloads and documentation of everything that goes wrong (and right). I am more than happy to do all this to help a willing developer create the port.

So if any developer(s) is interested, the dump can be downloaded from the GoogleDrive link below:
https://docs.google.com/file/d/0B4Y9UEEF5SVlT0lOczZ2S2hjUG8/edit?pli=1

Please let me know if this dump is ok as it is not a standard one. The current dump scripts did not work.
See here: http://chdk.setepontos.com/index.php?topic=9743.10
Basically, srsa_4c helped me to extract 16 files 4 of which were useful and they are included in the archive above.

Additionally, if any other people here would like to help test then please reply.

Cheers,

Tomek

DUMPE.BIN and DUMPF.BIN seem to have the right ROM content.

ROM layout (preliminary):
0xff000000 ... 0xffffffff : (DUMPF.BIN) some data(?), many holes
0xfe000000 ... 0xfeffffff : (DUMPE.BIN) DryOS ROM
  0xfe000000 ...          : bootloader
  0xfe020000 ...          : main firmware
0xfd000000                : mirror of 0xff000000 ... 0xffffffff
0xfc000000                : mirror of 0xfe000000 ... 0xfeffffff

edit:
great... it's not ARM??

DUMPE.BIN and DUMPF.BIN seem to have the right ROM content.
...
great... it's not ARM??

!

Nice of Canon to keep Canon basic working, I guess!

"DRYOS version 2.3, release #0052"

The "code" certainly doesn't look like ARM, but I'm not sure...
"ARM Library runtime error : signal=%d, type=%d"

"[module]=CO(Custom)",0xA
"[ver]=4. 8. 1. 57239",0xA
"[platform]=ARM(RVCT4.0[Build 902])",0xA
"[yuv_format]=Y0CbY1Cr",0xA
"[custom_no]=1",0

Could be leftovers I guess.

I though maybe the processor was in big-endian mode (which AFAIK doesn't change the instructions, but would cause the dump to be reversed) but that doesn't appear to be the case.

Could it be ARMv8 ? From what I understand the instructions still 32 bit, but the encoding is different, and not yet publicly documented http://kitoslab-eng.blogspot.com/2012/10/armv8-aarch64-instruction-encoding.html

If the code follows the pattern of current cams, then
ROM:FE020000                 DCB    0
ROM:FE020001                 DCB 0xF0 ; =
ROM:FE020002                 DCB    4
ROM:FE020003                 DCB 0xB8 ; +
ROM:FE020004 aGaonisoy       DCB "gaonisoy"
B804F000
should be branch instruction, jumping past the goanisoy. I think that's compatible with
010x 0100 iiii iiii iiii iiii iiix xxxx  -  b.c ADDR_PCREL19
edit
As philmoz points out, it doesn't 

There seems to be some confusion with what canon did with this ROM. Is there something I could do to help? Some other kind of dump? Or maybe upload the remaining "useless" files?

There seems to be some confusion with what canon did with this ROM. Is there something I could do to help? Some other kind of dump? Or maybe upload the remaining "useless" files?

It's not what Canon did with the dump, it's what Canon did with Digic 6. It does not appear to be the same CPU architecture as Digic 2 - 5

The strings in the dump show that the software is still similar, but the machine code is different.

The first step is identify the CPU architecture, but even if we can do that and get a working toolchain, porting CHDK won't be easy, if it's possible at all.

If it is ARMv8, gcc toolchains exist http://forums.arm.com/index.php?/topic/16154-where-can-we-find-the-opcode-for-armv8-instructions/ (see also http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html )

Getting this running and feeding the dumped binary to objdump could confirm or rule out that theory.

edit:
possibly more useful armv8 toolchain link http://jk.ozlabs.org/docs/arm64-toolchain/

I haven't got this working yet, the pre-built one doesn't run on my ancient ubuntu install

edit:
Nafraf pointed out this toolchain http://www.linaro.org/engineering/armv8/#tab3
Running
aarch64-linux-gnu-objdump -m aarch64 -b binary -D DUMPE.BIN > dumpe.dis

does not result in sensible output. Combined with my incorrect decoding above, I think this rules out the armv8 theory.

It looks like it could be thumb2. This would imply a newer arm arch, but not v8 (which makes sense, because v8 is very new)

fe020000: f000 b804 b.w 0xfe02000c
fe020004: 6167      str r7, [r4, #20]
fe020006: 6e6f      ldr r7, [r5, #100] ; 0x64
fe020008: 7369      strb r1, [r5, #13]
fe02000a: 796f      ldrb r7, [r5, #5]
fe02000c: f8df d084 ldr.w sp, [pc, #132] ; 0xfe020094
fe020010: f000 f828 bl 0xfe020064
fe020014: 4a20      ldr r2, [pc, #128] ; (0xfe020098)
fe020016: 6811      ldr r1, [r2, #0]
fe020018: f041 0101 orr.w r1, r1, #1
fe02001c: 6011      str r1, [r2, #0]
fe02001e: 481f      ldr r0, [pc, #124] ; (0xfe02009c)
fe020020: 491f      ldr r1, [pc, #124] ; (0xfe0200a0)
fe020022: 4b20      ldr r3, [pc, #128] ; (0xfe0200a4)
fe020024: 4299      cmp r1, r3
fe020026: bf3c      itt cc
fe020028: f850 2b04 ldrcc.w r2, [r0], #4
fe02002c: f841 2b04 strcc.w r2, [r1], #4
fe020030: d3f8      bcc.n 0xfe020024
This looks like "real" code to me rather than random disassembled garbage.

Note that fe020004-fe02000a are "gaonisoy"

disassembled using
aarch64-linux-gnu-objdump -m arm -Mforce-thumb2 --adjust-vma=0xFE000000 -b binary -D DUMPE.BIN > dumpe.thumb2.dis

edit:
For information about the thumb2 instruction set, I suggest the "The ARMv7-AR Architecture Reference Manual" found at  http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.architecture.reference/index.html (free registration required)

I thought I would join the party in this thread. I've purchased the SX270, which is pretty much the same as the SX280, except there's no GPS/WLAN. And as it seems, they both use a different architecture.

Anyway, I've dumped the firmware as well and it can be downloaded from here http://stuff.pfuender.net/shared/sx270_100c.7z.

From  nanomad (ML developer) in IRC

SX270: ARMv7e with thumb2

@pfuender
Thanks. In the case of the sx260/sx240, the firmwares were actually identical for a given firmware version (e.g. if they were both 100c, they were the same). Not clear if this is true for sx280/sx270 since yours is a different firmware version. There are definitely differences in the dumpe rom code, but it could just be different offsets due to firmware version.

Porting these is likely to be possible, but it will require substantial effort and some re-working of the core CHDK code, tools and build process to accommodate multiple CPU architectures. This will most likely require an experienced programmer who has access to the camera, blind porting would be very very difficult.

On big source of difficulty is that the current sig finder will need to be re-worked extensively, and all the functions found over again.

On the plus side, the fact the Canon code is in thumb2 should eliminate the need for interworking on our side.

FYI:

Everyone be aware that due to battery indicator issues while videoing, Canon has acknowledge the issue and will likely release new f/w version to fix.

Likely not a huge f/w change but then again???

@reyalP: are the DUMPE dumps full & correct, can/should i add those to the repository ?