Windows GUI for CHDK porting

  • 92 Replies
  • 26098 Views
*

Offline srsa_4c

  • ******
  • 3135
  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #60 on: 20 / July / 2012, 00:53:31 »
    Advertisements
    I think you will find that those are both correct - although the GPL one is confusing if you don't know what its doing.
    It's only meant as reference (I would expect MOV R1, #0x4000000 here).

    What GCC didn't like was another line
    /tmp/ccJW5HLx.s:1026: Error: constant expression expected -- `mov R3,#C8,0x16'
    located at:
    ROM:FF0C2E64 0xE3A03BC8    MOV     R3, #C8,0x16
    and should be
    MOV R3, #0x32000

  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #61 on: 20 / July / 2012, 01:05:16 »
    It's only meant as reference (I would expect MOV R1, #0x4000000 here).
       
    Code: [Select]
    MOV     R1, #0x40,0xC means the same thing - two ways of expressing the same immediate operator.

    Quote
    What GCC didn't like was another line
    /tmp/ccJW5HLx.s:1026: Error: constant expression expected -- `mov R3,#C8,0x16'
    located at:
    ROM:FF0C2E64 0xE3A03BC8    MOV     R3, #C8,0x16
    and should be
    MOV R3, #0x32000

    Which I think confirms that CHDK-PT should have generated
     
    Code: [Select]
       MOV R3,#0xC8,0x16rather than
    Code: [Select]
       MOV R3,#C8,0x16
    as 0xC8 ring shifted right through a 32 bit word by 22 bits (0x16) is 0x32000

    Its not flagging the 1st operand as being a hex value.

    If so, this is clearly a bug in CHDK-PT.  Strange nobody noticed this so far - just luck that most of the C tasks don't try to load immediate any big numbers maybe ?


    « Last Edit: 20 / July / 2012, 01:42:40 by waterwingz »

    *

    Offline srsa_4c

    • ******
    • 3135
  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #62 on: 20 / July / 2012, 08:46:24 »
    Disabling the following special case seems to do the trick.
    Code: (diff) [Select]
    --- chdk_dasm.c (revision 29)
    +++ chdk_dasm.c (working copy)
    @@ -828,7 +828,7 @@
                   /* immediate constant */
                   unsigned long imm8 = (instr&255);
                   unsigned long rot  = (instr>>7)&30;
    -              if (rot && !(imm8&3) && c=='*') {
    +              if (0) {//(rot && !(imm8&3) && c=='*') {
                     /* Funny immediate const. Guaranteed not '.', btw */
                     *op++='#'; // *op++='&';
                     *op++="0123456789ABCDEF"[imm8>>4];
    BTW, I haven't been able to find this
    Code: [Select]
    MOV R3,#0xC8,0x16syntax anywhere.
    Strange nobody noticed this so far - just luck that most of the C tasks don't try to load immediate any big numbers maybe ?
    It's quite common in earlier VxWorks generation cameras' firmware, but not much of those is being ported nowadays :)

  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #63 on: 20 / July / 2012, 09:06:47 »
    Disabling the following special case seems to do the trick  ..
    Thanks for that - I'll take a look later today.  Went to bed last night rather that dig right into it.  FWIW, I found the original disassembler code online but it took a lot of work to get it functional for ARM4 and to track down other bugs.

    Quote
    BTW, I haven't been able to find this
    Code: [Select]
    MOV R3,#0xC8,0x16syntax anywhere.
    This was my first time with ARM assembler - the syntax came for free with the original code :) Woke up this morning and decide it should be changed.  Curious that the gcc compiler does not have problems with it (as long as the 0x part is in there).

    It's quite common in earlier VxWorks generation cameras' firmware, but not much of those is being ported nowadays :)
    Hopefully.  Might take a look at a few of the cams that I know were ported with CHDK-PT with a grep string and see what I can find. Want to make sure its not putting value less than 256 bytes in as decimal rather than hex (for example). 


  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #64 on: 20 / July / 2012, 22:20:09 »
    New release 2.03 now available.

    Updated to remove bug identified and fixed by srca_4c.   Loading a register with an immediate value >255 creates a output line that cannot be compiled or that compiles incorrectly.

    Also updated with some cleanup of the memory dump info.



    « Last Edit: 20 / July / 2012, 22:22:06 by waterwingz »

  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #65 on: 02 / September / 2012, 16:16:47 »
    Released 2.04 last week and forgot to post a note here.  This was mostly a cosmetic update - the text window is now much wider and uses a larger fixed point font.   I was having trouble using chdk-pt on linux under Wine - the text window was unreadable.

    Update : small bump to 2.05 - just cleans up the output format when an illegal or undefined instruction is encountered (for example, in a data table) so that the data at that address is displayed cleanly
    « Last Edit: 08 / September / 2012, 14:54:06 by waterwingz »

  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #66 on: 11 / September / 2012, 20:20:41 »
    One litle bug, Tested in sx260 finally :D,
    and the functions copied in ram for the new cams, indentified by chdk-pt as FC.....  hangs the camera,  It should name them 00..... instead of FC
    Released 2.06 today to fix this.  Finally.

    Turns out the original disassembler code assumed that when a B or BL instruction has a positive offset value that takes it past the end of memory (0xFFFFFFFF),  it should wrap to 0xFC000000 rather than 0x00000000.    Maybe some early ARM chips worked that way ? 

    I simplified the code to just do a regular binary 2's complement add and it now calculates the right address.

    Thanks to nafraf for providing test cases for this.


    *

    Offline srsa_4c

    • ******
    • 3135
  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #67 on: 03 / January / 2013, 21:20:31 »
    Patch to enable 0xf8000000 as fw start address. I may have missed a few spots, and "Y series" is probably not the best description   ;)


  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #68 on: 03 / January / 2013, 21:49:42 »
    Patch to enable 0xf8000000 as fw start address. I may have missed a few spots, and "Y series" is probably not the best description   ;)
    Thanks.   

    I was actually thinking about this the other day - I've never been happy with the "A", "X", and "S" designations as a way to pick your camera type.  One option I considered was a .ini file with every [camera model name | load address ] pair. Its gets to be a long list to scroll through though.

    Another was to just let you specify the start address manually. 

    But my final idea was whether the program can just guess the start address by the  PRIMARY.BIN  file size you load ?  I think fe50 has most of them sized correctly in the Google repositiry where possible.  So far,  I think we have seen 4M, 8M & 16M ROMS.   I assume the S110 is a 32M ROM ?  Do the start addresses work like 4M = 0xFFC00000 ,  8M = FF810000 , 16M = 0xFF000000 and 32M = 0xF8000000 for all cameras ?

    In the meantime,  I'll just apply your patch while I think about it.

    « Last Edit: 03 / January / 2013, 21:51:23 by waterwingz »

    *

    Offline srsa_4c

    • ******
    • 3135
  • Publish
    Re: Windows GUI for CHDK porting
    « Reply #69 on: 03 / January / 2013, 22:01:57 »
    One option I considered was a .ini file with every [camera model name | load address ] pair. Its gets to be a long list to scroll through though.
    ... and is a pain to maintain.

    Quote
    Another was to just let you specify the start address manually. 
    I'd prefer this.

    Quote
    But my final idea was whether the program can just guess the start address by the  PRIMARY.BIN  file size you load ?
    No. There's no guarantee that the ROM is from that repo. And...
    Quote
    I assume the S110 is a 32M ROM ?
    it's not, probably 16M.

     

    Related Topics