SX280 HS 101B Dump - I am truly willing to help test if someone develops - page 2 - Firmware Dumping - CHDK Forum
« previous next »
Pages: 1 [2] 3 4 5 6   Go Down

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

  • 54 Replies
  • 45297 Views
*

Offline nafraf

  • *****
  • 1308
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #10 on: 26 / May / 2013, 07:18:32 »
Advertisements
Firmware size seems to be >16M, Camera model and P-ID are in DUMPF.
SX280:
Code: [Select]
$ dd if=DUMPF.BIN bs=1 skip=$((0x00f601e0)) count=24
Canon PowerShot SX280 HS24+0 records in

$ hexdump  -n 2 -s0xf60040 DUMPF.BIN
0f60040 325f
SX270:
Code: [Select]
$ dd if=DUMPF.BIN bs=1 skip=$((0x00f601e0)) count=24
Canon PowerShot SX270 HS24+0 records in

$ hexdump  -n 2 -s0xf60040 DUMPF.BIN
0f60040 3260
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #11 on: 26 / May / 2013, 07:21:01 »
@fe50
(The question was not directed to me, hope you don't mind)

IMHO we don't know yet how the final version of dump will look like, guess we'll have to wait for the first successful port. In the meantime, you could store the dumpe+dumpf or dumpc+dumpd files.
Some things to consider:
- ROM areas are mirrored. I think that the correct address for the main ROM is the 0xFCxxxxxx range (constants in the bootloader and in ROM seem to indicate that).
- main ROM starts at (if my above assumption is correct) 0xFC020000, after the bootloader
- about 40% of the main ROM's 16MB segment is unused, consists of 0xff bytes
- the camera's name doesn't appear in main ROM
- the other ROM segment (0xFDxxxxxx or 0xFFxxxxxx) seems to hold the camera dependent data (adjustment areas, camera name, romlog, who-knows-what-else), but it has large unused areas

And a fun fact: the ROMLOG seems to be the binary + text combination again  (sx270, dumpf).
Logged
*

Offline tzurek

  • *
  • 10
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #12 on: 28 / May / 2013, 01:13:46 »
Sorry guys, I will have to step away from my offer to test firmware. I am going to go to Africa in 2 months and this seems like something that requires an experienced programmer with access to the camera. I was able to exchange my Sx280HS for a SX260HS so that I can use the working port.

Sorry about that. Good luck though, the SX280 is a great camera and it may be that all future cameras have different architecture.
Logged
*

Offline pfuender

  • *
  • 2
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #13 on: 18 / July / 2013, 17:02:29 »
I didn't check it out in detail yet, but Canon released a firmware upgrade for the bug causing low-battery when recording video.
https://www.canon-europe.com/Support/System/Search.aspx?TcmUri=tcm:13-1062664. The ZIP provided contains the .FI2 upgrade file, not sure if that helps any further.
Logged
*

Offline Pge-tips

  • *
  • 4
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #14 on: 19 / August / 2013, 19:22:38 »
Hi ,
I recently bought a SX280 HS (Belgium) and updated the firmware to
GM1.02B (1.0.2.0). I'm also interested in a CHDK port for this new camera.
My programming skills are rather limited, but I'm familiar with SW testing.
So if there is something I could do to boost the developement ... just let me know.
Regards

PGe-Tips
Logged
*

Offline user941

  • *
  • 3
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #15 on: 29 / August / 2013, 11:46:32 »

Thanks for this. The only reason I haven't gotten an SX280 yet is the lack of CHDK. Thanks to all developers and people volunteering their time !
Logged
*

Offline robertb

  • *
  • 11
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #16 on: 05 / September / 2013, 21:41:35 »
I can confirm that the firmware does seem to start at FC020000, and I've modified the dumper script to account for that.

In IDA (v6.4), I set the processor architecture to ARM (not ARMB), and the specific type to ARMv7-A&R. Since IDA apparently enables THUMB instructions using a fake register T, I set that register (alt-G) to 1, pressed C at address FC020000, and got valid code that begins with a jump over the signature:

Code: [Select]
ROM:FC020000                 CODE16
ROM:FC020000                 B.W             loc_FC02000C
ROM:FC020000 ; ---------------------------------------------------------------------------
ROM:FC020004                 DCB 0x67 ; g
ROM:FC020005                 DCB 0x61 ; a
ROM:FC020006                 DCB 0x6F ; o
ROM:FC020007                 DCB 0x6E ; n
ROM:FC020008                 DCB 0x69 ; i
ROM:FC020009                 DCB 0x73 ; s
ROM:FC02000A                 DCB 0x6F ; o
ROM:FC02000B                 DCB 0x79 ; y
ROM:FC02000C ; ---------------------------------------------------------------------------
ROM:FC02000C
ROM:FC02000C loc_FC02000C                            ; CODE XREF: ROM:FC020000j
ROM:FC02000C                 LDR.W           SP, =0x80010000
ROM:FC020010                 BL              sub_FC020064
ROM:FC020014                 LDR             R2, =0xC0242010
ROM:FC020016                 LDR             R1, [R2]
ROM:FC020018                 ORR.W           R1, R1, #1
ROM:FC02001C                 STR             R1, [R2]
ROM:FC02001E                 LDR             R0, =0xFC9538D4
ROM:FC020020                 LDR             R1, =0x10C1000
ROM:FC020022                 LDR             R3, =0x10E03C4
ROM:FC020024
ROM:FC020024 loc_FC020024                            ; CODE XREF: ROM:FC020030j
ROM:FC020024                 CMP             R1, R3
ROM:FC020026                 ITT CC
ROM:FC020028                 LDRCC.W         R2, [R0],#4
ROM:FC02002C                 STRCC.W         R2, [R1],#4
ROM:FC020030                 BCC             loc_FC020024
ROM:FC020032                 LDR             R0, =0x10C1000
ROM:FC020034                 LDR             R1, =0x1F3C4
ROM:FC020036                 BL              sub_FC12DD3A
ROM:FC02003A                 LDR             R0, =0xFC932474
ROM:FC02003C                 LDR             R1, =0x8000
ROM:FC02003E                 LDR             R3, =0x29460
and so on. Next step, see if I can find any asserts.
Logged
*

Offline reyalp

  • ******
  • 14137
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #17 on: 05 / September / 2013, 22:29:02 »
Quote from: robertb on 05 / September / 2013, 21:41:35
and so on. Next step, see if I can find any asserts.
Essentially any string ending in .c ("FsIoNotify.c" is an example) should lead you to one.
Logged
Don't forget what the H stands for.
*

Offline Tyrion1984-it

  • *
  • 1
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #18 on: 06 / September / 2013, 09:31:35 »
Thanks to all of you that are working on chdk for powershot sx 280 hs, I will eagerly wait to try it out
Logged
*

Offline reyalp

  • ******
  • 14137
Re: SX280 HS 101B Dump - I am truly willing to help test if someone develops
« Reply #19 on: 06 / September / 2013, 13:28:22 »
@robertb
From my preliminary examination of the code, it doesn't look like it has changed that much, it's just DryOS R52 compiled for a different processor. So one approach is to go through a firmware dump of an already ported camera, and find equivalent functions based on "signposts" like strings, common constants, or sequence of calls to already known functions. In the current source trunk source, you can get the names and addresses of a bunch of known functions (in an existing port) from the funcs_by_*.csv files. There are also some IDA files http://chdk.wikia.com/wiki/Loading_dump_to_IDA (note these won't work as-is on your thumb2 dump, they would only help you work from an old style ROM)

To get something booting, it would be good to have an LED. You might be able to find this from dis assembly of LED related functions or brute froce, but sometimes just trying known MMIO addresses from other cameras is quicker. You can use Canon Basic http://chdk.wikia.com/wiki/Canon_Basic to poke.

Once you have an LED, you can attempt to make a diskboot.bin that just loads and sits in a loop blinking the LED. Beware that the diskboot.bin may need some minimum size to actually load correctly, padding it out to 64k or something is probably a good idea.

Getting a full version of CHDK working will require quite a bit of other work, since the current code expects ARM/Thumb only.
Logged
Don't forget what the H stands for.
Pages: 1 [2] 3 4 5 6   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal