S5IS - Ported! - page 2 - DryOS Development - CHDK Forum supplierdeeply

S5IS - Ported!

  • 111 Replies
  • 85765 Views
*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
S5IS 1.01b - Ported!
« Reply #10 on: 07 / April / 2008, 17:36:54 »
Advertisements
Hmm... It seems you did not edit constatnts in boot.c:boot() ater copying from A720:

A720:
Code: [Select]
    long *canon_data_src = (void*)0xFFE9C5D0;
    long *canon_data_dst = (void*)0x1900;
    long canon_data_len = 0xfc04 - 0x1900; // data_end - data_start
    long *canon_bss_start = (void*)0xfc04; // just after data
    long canon_bss_len = 0x9d024 - 0xfc04;

S5IS:
Code: [Select]
    long *canon_data_src = (void*)0xFFE9C5D0;
    long *canon_data_dst = (void*)0x1900;
    long canon_data_len = 0xfc04 - 0x1900; // data_end - data_start
    long *canon_bss_start = (void*)0xfc04; // just after data (A710: 0xD680)
    long canon_bss_len = 0x9d024 - (0xfc04 - 0x1900); // 0x9d024 - (0xfc04 - 0x1900) (a710: 0x9F9B0 - 0xD680)


But the constants:
A720:
Code: [Select]
ROM:FFC00188 off_FFC00188    DCD unk_FFE9C5D0                  ; DATA XREF: RestartDevice-1B774r
ROM:FFC0018C dword_FFC0018C  DCD 0x1900                        ; DATA XREF: RestartDevice-1B770r
ROM:FFC00190 dword_FFC00190  DCD 0xF0C4                        ; DATA XREF: RestartDevice-1B76Cr
ROM:FFC00194 dword_FFC00194  DCD 0x9D024                       ; DATA XREF: RestartDevice-1B758r

S5IS:
Code: [Select]
ROM:FF81019C off_FF81019C    DCD unk_FFB07EB8        ; DATA XREF: RestartDevice-1CBDCr
ROM:FF8101A0 dword_FF8101A0  DCD 0x1900              ; DATA XREF: RestartDevice-1CBD8r
ROM:FF8101A4 dword_FF8101A4  DCD 0x1056C             ; DATA XREF: RestartDevice-1CBD4r
ROM:FF8101A8 dword_FF8101A8  DCD 0x9B610             ; DATA XREF: RestartDevice-1CBC0r
CHDK Developer.

*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
S5IS 1.01b - Ported!
« Reply #11 on: 07 / April / 2008, 17:40:09 »
Hm, I guess. I didn't know what they did and it worked, so I ignored them. Maybe this is why 0x9B610 didn't work... I'll test it in my debug-build and fix it ASAP.

Anyway, I found another issue since I-don't-know-when. The ubasic shoot command used to work fine, though now it doesn't anymore. I *THINK* I have found the source of this cause... the shoot command does not release shoot_half, therefore the camera stays in some in-progress mode, therefore shooting_in_progress never returns false until that button is released and therefore the script does not continue. Raising/closing the flash seem to shortly set PROPCASE_SHOOTING to 0, so that will continue the script. I still have to figure out a way to fix this and I need to find out why it worked before. This is probably something camera-specific which needs to be worked around.

Oh wait, I just figured it out partially. I only tested the shoot command with my external flash (580EX II) on. This unit causes the camera to shortly set PROPCASE_SHOOTING to 0. Therefore it will continue shooting.

*

Offline ewavr

  • ****
  • 1057
  • A710IS
S5IS 1.01b - Ported!
« Reply #12 on: 07 / April / 2008, 17:47:13 »
Hmm... It seems you did not edit constatnts in boot.c:boot() ater copying from A720:
S5IS:
Code: [Select]
    long canon_bss_len = 0x9d024 - (0xfc04 - 0x1900); // 0x9d024 - (0xfc04 - 0x1900) (a710: 0x9F9B0 - 0xD680)

And from very old version of A720, because 0x1900 subtraction is error here (I searched  for this error two days  :().
« Last Edit: 07 / April / 2008, 18:07:55 by ewavr »

*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
S5IS 1.01b - Ported!
« Reply #13 on: 07 / April / 2008, 17:50:56 »
By the way, I think I found the keyboard problem... it just came to me and then I looked into the A720 keymap. KEY_SHOOT_HALF = 0x40000000, key_shoot_full = 0xC0000000 (== 0x80000000 | 0x40000000). I have those separately in my keymap. I guess fixing that should fix the shoot problem. First I need to have some more food, though :)


*

Offline critical1

  • *
  • 7
  • Powershot S5is - 1.01a
S5IS 1.01b - Ported!
« Reply #14 on: 07 / April / 2008, 18:05:42 »
Congratulations on your new S5 CHDK, all that need doing now is ironing out the bugs :) which looks like its already happening... Super fast and Super COOL.

Critical1
Critical1
Powershot S5is - 1.01a

*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
S5IS 1.01b - Ported!
« Reply #15 on: 07 / April / 2008, 18:42:50 »
OK, busy with the changes now, almost done except for ewavr's stuff. I figured out that I have to compile CHDK (or at least copy stubs_auto.S after compiling to my work-trunk to commit) because stubs_auto.S is not regenerated after a fresh svn checkout (modification time is the same as boot.c). That's why building initially failed for me (so changeset 370 was unnecessary) after checking it out, while it worked fine with a copy of my own trunk. I'm still looking into it a bit, but I guess I'll just commit an up-to-date stubs_auto.S.

*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
S5IS 1.01b - Ported!
« Reply #16 on: 07 / April / 2008, 19:02:18 »
No compilation errors more. :)

and one theoretical :) question: if we change some "illegal" for this assembler instructions like BLX R12 to their opcodes (.long 0xE12FFF3C), this can work? (of course, instruction must do not contain relative to PC offsets (like LDR))
I'm sorry, I completely missed this question. Anyway, as I documented (don't know if you read that), I compiled an extra compiler without the --with-cpu=arm9 flag. This causes the compiler to use the default ARM cpu, I don't really know which one. It just seems that 'arm9' does not support BLX Rn or STRD (among a few others), but the camera does. I verified this by checking the opcode from the original firmware bit-by-bit and 'my' compiler generated the exact same opcode as in the camera, so I'd say using the direct opcode would work (though the assembler might complain). I also did see a distinct difference between BLX R12 and MOV LR, PC + MOV PC, R12 in the generated code, but the behaviour was identical (unless R12 has a thumb-address), so it works. I also did not notice any new errors being introduced after switching back to the 'official' compiler.

I accidentally discovered this because I was too lazy to actually compile a 'chdk-gcc', so I used the toolchain I use for my iPod. This one had some problem with floating-point math, causing the camera to crash, so I had to build a new toolchain anyway. I just hated that compiler lying to me so I found this way to create a compiler which has the correct fp-math things and doesn't whine about those instructions.

As far as code is concerned, I think (or remember from documentation) the --with-cpu=arm9 is a flag which only tells the ASSEMBLER what architecture to assemble for. Both compilers gave me an identical BOOTDISK.BIN, at least in filesize. I didn't checksum them or whatever. I think it's safe to use the compiler with this flag but obviously more models have to be tested and everyone has to agree. For now, I'm fine with this workaround, the BLX opcodes should never be called from thumb (CHDK) anyway, as far as I've discovered them.

Edit: commit done, binary version updated.
« Last Edit: 07 / April / 2008, 19:10:09 by DataGhost »

*

Offline ewavr

  • ****
  • 1057
  • A710IS
S5IS 1.01b - Ported!
« Reply #17 on: 07 / April / 2008, 19:29:15 »
Interesting that Windows toolchain do not generate in stubs_auto.S such lines:
STUB(163), STUB(2), STUB(20), STUB(70) etc. from commented lines:
// "BL nullsub_163\n"


*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
S5IS 1.01b - Ported!
« Reply #18 on: 07 / April / 2008, 19:54:01 »
Hm, I know why.

Windows: grep -E 'B.*[[:space:]]+sub_[0-9A-Fa-f]'
Linux:   grep    'B.*[[:space:]]*sub_[0-9A-Fa-f]'

Because the Linux version doesn't require any spaces, it'll just match 'BL    null' with the 'B.*' part alone, match no spaces and then match the sub. Easily overlooked, heh. I'll fix it tomorrow morning, if nobody did it already in the meantime (this probably also happens on other platforms, I copied it from A720). For now, I'm just going to fiddle with the full CHDK a bit, read up on all the news I missed today and get some sleep afterwards.

*

Offline pethead

  • *
  • 42
  • Canon S5 IS
    • Canon S5 IS Community
Re: S5IS 1.01b - Ported!
« Reply #19 on: 08 / April / 2008, 02:28:26 »
installation method of this CHDK is the same as standard or non-trivial like on A650IS?
canons5is.clan.su Allbest+ with timestamp features

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal