supplierdeeply

Porting chdk to the G9

  • 245 Replies
  • 61360 Views
  • Publish
    Re: Porting chdk to the G9
    « Reply #150 on: 09 / June / 2008, 08:35:33 »
    Advertisements
    Hm, it's been a while and I don't remember how I solved it... I don't think the remaining code had anything to do with it. As you're suggesting, something else is probably wrong long before getting to hwsetup. Are you using a LED to indicate that your code is being executed? Are you using a delay for the LED?

    Yes I've used various led, with and without delay.

    Thanks for the interest!

    Anyway I'm rechecking the previous subs in boot.c, like jeff666 suggested, but they seems correct compared to ida's dump.

    *

    Offline DataGhost

    • ****
    • 314
    • EOS 40D, S5IS
      • DataGhost.com
  • Publish
    Re: Porting chdk to the G9
    « Reply #151 on: 09 / June / 2008, 08:45:15 »
    Well, if you turn on the led, delay, turn it off, delay again and then jump back to the firmware (restart/beginning), it should keep blinking. If it doesn't, something else is wrong before there... if it does you can continue hooking stuff until it doesn't restart anymore.

  • Publish
    Re: Porting chdk to the G9
    « Reply #152 on: 09 / June / 2008, 08:58:58 »
    Well, if you turn on the led, delay, turn it off, delay again and then jump back to the firmware (restart/beginning), it should keep blinking. If it doesn't, something else is wrong before there... if it does you can continue hooking stuff until it doesn't restart anymore.

    Already done, but can't find a solution.

  • Publish
    Re: Porting chdk to the G9
    « Reply #153 on: 09 / June / 2008, 14:31:33 »
    Hi All,

    Does anyone know when there will be a firmware version that is ready for testing? I have a G9, which I am keen to try out with the CHDK features. Unfortunately I am not familiar with the ARM processor, which it appears that this uses extensively.

    I am happy to help with testing, once that stage is reached. I am involved with development work, so am happy to report bugs and help out, if that will speed things up.


  • Publish
    Re: Porting chdk to the G9
    « Reply #154 on: 09 / June / 2008, 18:43:42 »
    looks like they hit a road block D:

  • Publish
    Re: Porting chdk to the G9
    « Reply #155 on: 10 / June / 2008, 07:37:03 »
    looks like they hit a road block D:

    Who?

  • Publish
    Re: Porting chdk to the G9
    « Reply #156 on: 10 / June / 2008, 19:29:30 »

  • Publish
    Re: Porting chdk to the G9
    « Reply #157 on: 12 / June / 2008, 08:17:57 »


  • Publish
    Re: Porting chdk to the G9
    « Reply #158 on: 13 / June / 2008, 03:09:33 »
    I don't understand what is wrong, the reset-code seems to work, the fist subs in boot.c are correct.

    *

    Offline dlw

    • *
    • 22
  • Publish
    Re: Porting chdk to the G9
    « Reply #159 on: 15 / June / 2008, 16:36:51 »
    @Jeff666:  Now that I've had time to read the code you put together for the G9, I am surprised at the amount of work you've done for us.  This is pure altruism on your part -- thank you.

    @Bongo_bingo:  After a series of false starts, I've caught up to you -- at least as far as boot.c is concerned.  I agree that the first hurdle is that sub_FF812D70 doesn't return.  I started hooking in code from the firmware:
       sub_FF812D70_my -> sub_FF815EBC_my -> sub_FF816ED0_my -> sub_FF818BC8_my
    and then processing stopped in sub_FF818BC8_my when "STRNE R1, [R2, #4]" was executed.

    Now I can think of a couple of reasons why a "store to memory" instruction would crash -- but none of them *should* happen.  In looking at the instruction sequence:
       R2 is loaded from memory at the address in R0+4.
       Its value is compared to zero.
       The value is not zero, so the CPU attempts to store something at [R0+4+4] -- and fails.
    Previously (in sub_FF816ED0_my), R0 is set to 0x1A3C -- so the problem seems to be the contents of memory at 0x00001A40.

    Because the code for the A720 and the S5 seems similar -- and both work -- I suspect that we are doing something earlier in boot.c that is having unexpected consequences.  I'll keep looking as I have time.

    I've attached my boot.c.  It turns on the power LED when it enters sub_FF810FB8_my, then uses the ISO LED for debugging the following functions.  I moved to using  R12 and R13 for the assembly language LED-off routine after discovering that sub_FF816ED0 uses R8.

    Hope this helps a bit.

     

    Related Topics