Windows GUI for CHDK porting - page 7 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 4 5 6 [7] 8 9 10   Go Down

Windows GUI for CHDK porting

  • 98 Replies
  • 131788 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: Windows GUI for CHDK porting
« Reply #60 on: 20 / July / 2012, 00:53:31 »
Advertisements
Quote from: waterwingz on 20 / July / 2012, 00:38:01
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
Logged
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #61 on: 20 / July / 2012, 01:05:16 »
Quote from: srsa_4c on 20 / July / 2012, 00:53:31
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 »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 4451
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.
Quote from: waterwingz on 20 / July / 2012, 01:05:16
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 :)
Logged
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #63 on: 20 / July / 2012, 09:06:47 »
Quote from: srsa_4c on 20 / July / 2012, 08:46:24
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).

Quote from: waterwingz on 20 / July / 2012, 01:05:16
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). 
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
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 »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
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 »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #66 on: 11 / September / 2012, 20:20:41 »
Quote from: asm1989 on 15 / April / 2012, 11:02:27
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.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 4451
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   ;)
Logged
*

Offline waterwingz

  • ******
  • 12134
    • Waterwingz
Re: Windows GUI for CHDK porting
« Reply #68 on: 03 / January / 2013, 21:49:42 »
Quote from: srsa_4c 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   ;)
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 »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 4451
Re: Windows GUI for CHDK porting
« Reply #69 on: 03 / January / 2013, 22:01:57 »
Quote from: waterwingz on 03 / January / 2013, 21:49:42
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.
Logged
Pages: 1 2 3 4 5 6 [7] 8 9 10   Go Up
« previous next »
 

Related Topics