G3 X 1.00C FW Dump - page 2 - Firmware Dumping - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2] 3   Go Down

G3 X 1.00C FW Dump

  • 24 Replies
  • 17118 Views
*

Offline reyalp

  • ******
  • 14039
Re: G3 X 1.00C FW Dump
« Reply #10 on: 04 / February / 2016, 15:42:46 »
Advertisements
Quote from: srsa_4c on 04 / February / 2016, 12:48:02
Quote
How do I use and dereference pointers in Canon Basic?
We don't know all details of this language. I'd probably use the peek event procedures that are registered by System.Create: Peek8, Peek16, Peek32 - for addresses, you obviously need Peek32.
You can actually use *foo syntax. Spacing determines whether it's multiplication or pointer de-ref  :-[

Some notes in http://chdk.wikia.com/wiki/Canon_Basic#Language_documentation

edit:
FWIW, I have been including the g3x dump in my finsig_thumb2 tests. I expect that most of the found values are good.
« Last Edit: 04 / February / 2016, 15:44:25 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline Nippey

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #11 on: 07 / February / 2016, 08:07:07 »
Hi srsa,

I'm really impressed how fast you can work through the assembler.

Quote
The function I'd call LEDtable_init is sub_fc075dc4. The suspicious values there are 0x21 and 4.

I was so close.. I also found these values but was irritated because this function seemed to write random values into the members [0,1,5,6,7] of the array I identified.
Yes, I also found 0xd20b0000 + 0x800 as well as the On/Off values 0x4d0002 and 0x4c0003.

Quote
I'm assuming you do follow reyalp's work on the D6 sigfinder - it's progressing pretty well.

Haha unfortunately no. I basically tried to work *offline* through the assembly since my last post in december.
I printed out the objdump disassembly of "task_LEDCon" and "taskcreate_LEDCon" and all referenced functions.
Then I took the ARM assembler documentation and tried to find breadcrumbs in this mess of instructions:D

I just read through reyalp's thread... Cool
So I guess I could use his software to confirm the findings I already made? This sounds really good.
I'll try it out when I find the time as I am curious if it can identify the missing handful of functions I didn't find yet.


Quote
How do I use and dereference pointers in Canon Basic?

I just got it!  :-X
There was a syntax error in my script.

Code: [Select]
'Based on the Dumper Script
startaddr = 0x9BAC
startptr = *startaddr
romsize = 504

sprintf(msgstr,"Adr %0X",startaddr)
PutMsg(msgstr)
sprintf(msgstr,"Ptr %0X",startptr)
PutMsg(msgstr)
 
dumpfile = Fopen_Fut("A/PRIMARY.BIN","w")
Fwrite_Fut(startaddr,romsize,1,dumpfile)
Fclose_Fut(dumpfile)

I got the following output as well as a dump of the memory:
Adr 9BAC
Ptr 36AE10

Unfortunately, the dump didn't contain anything useful.

(Hmm, I found a lot of instructions that jump into some weird memory range "0xBFE158A8" or so.
Maybe I can dump that too.....)


So I continued with your addresses and it worked!! Thanks!!

Code: [Select]
  led1addr = 0xd20b0884
  led2addr = 0xd20b0810
 
  Poke32(led2addr, 0x4d0002)  'It is ON now!!
  *led2addr = 0x4d0002        'Works, too!
   
  Poke32(led1addr, 0x4c0003)  'It is OFF now!!
 
Interestingly, each time I try to read the value of the addresses (using dereferencing or Peek32), I just get "5C" as value.
So, Poke32, Peek32 is equal to pointer-usage in Canon Basic.

Code: [Select]
0xd20b0884 'Status light - Back facing green LED
0xd20b0810 'Focus helper - Front facing white LED

There is a lot of knowledge hidden here.
Each time I crawl through the forum, the wiki pages or the Repository, I find something new.
If I knew a way to glue this all together, I'd try to help. :')


Next step is to collect more information about running self-compiled programs.
And try the same thing in C.

Thank you all for your patience!
Logged
*

Offline Christian72D

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #12 on: 13 / April / 2020, 03:02:10 »
Anyone still working on this camera?

I love it, i only miss a GOOD feature of taking panorama HDRs. So i would need CHDK for this. :(
Logged
*

Offline ranma

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #13 on: 04 / May / 2020, 15:32:29 »
> Anyone still working on this camera?

I bought a G3X last year and I've spent some work on porting to my G3X this (extended) weekend, I've now got it booting (in playback mode only) and showing the initial CHDK messages, but none of the hooks are implemented yet (except for the InitFileModules hook).
Logged
*

Offline reyalp

  • ******
  • 14039
Re: G3 X 1.00C FW Dump
« Reply #14 on: 04 / May / 2020, 15:59:42 »
Quote from: ranma on 04 / May / 2020, 15:32:29
> Anyone still working on this camera?

I bought a G3X last year and I've spent some work on porting to my G3X this (extended) weekend, I've now got it booting (in playback mode only) and showing the initial CHDK messages, but none of the hooks are implemented yet (except for the InitFileModules hook).
Welcome, and nice work :)

G3X should be a relatively straightforward Digic 6 port at this point, I think. Other DryOS 57 ports are SX710 and M10.

Ghidra version tracking can be quite helpful https://chdk.fandom.com/wiki/Ghidra_Version_Tracking_workflow_for_porting
Logged
Don't forget what the H stands for.
*

Offline ranma

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #15 on: 04 / May / 2020, 16:25:29 »
Quote from: reyalp on 04 / May / 2020, 15:59:42
Welcome, and nice work :)

G3X should be a relatively straightforward Digic 6 port at this point, I think. Other DryOS 57 ports are SX710 and M10.

Ghidra version tracking can be quite helpful https://chdk.fandom.com/wiki/Ghidra_Version_Tracking_workflow_for_porting

Yes, it's been fairly straight-forward so far thanks to all the work that has gone into the great sigfinder tooling.

And it helps that it is also not my first rodeo with low-level firmware hacking. :)
I probably should look into Ghidra at some point, so far I've been using an ancient version of ida (and a small python script to convert the auto-detected .csv symbol list into an .idc to load)...

It's also really helpful that that are a number of Digic-6 cams in the tree already, I've started with the G5X port for reference since I guess it will be the best fit, but looking at M10 and G16 ports has been helpful as well.
Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: G3 X 1.00C FW Dump
« Reply #16 on: 08 / May / 2020, 10:55:22 »
Quote from: ranma on 04 / May / 2020, 16:25:29
It's also really helpful that that are a number of Digic-6 cams in the tree already, I've started with the G5X port for reference since I guess it will be the best fit, but looking at M10 and G16 ports has been helpful as well.

FWIW, I did the G16 port entirely with the capdis tool included in the CHDK source tree.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline ranma

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #17 on: 11 / May / 2020, 07:03:54 »
So I'm still having issues with the live view crashing in particular in 1080p mode over HDMI, maybe because CHDK is taking up too much memory or is causing some subtle timing issue somewhere. It works for a while, but usually crashes within a minute or so.

However here is a Canon Basic script for enabling clean overlays on G3 X firmware 110E (adopted from srsa_4c example for M100):
Code: [Select]
' clean rec mode palette
' G3X, 110e

DIM palette_buffer_ptr = 0x15dbc
DIM palette_to_zero = 0
DIM msg = 0

public sub check_compat()
    check_compat = 0
    if strcmp("EC385\n\r",0xfc000584) = 0 then
        exit sub
    end if
    if strcmp("GM1.10E",0xfc54e0b5) = 0 then
        check_compat = 1
        exit sub
    end if
end sub

private sub palette_mod()
    adr = *palette_buffer_ptr
    adr = adr + (palette_to_zero * 4)
    if *adr <> 0 then
        adr = *adr + 4
        memset(adr, 0, 256 * 4)
    end if
end sub

private sub setup()
    System.Create()
    UI.CreatePublic()
    msg=LCDMsg_Create()
    LCDMsg_Move(msg,10,200)
    LCDMsg_ChangeColor(msg, 2)  ' Green
    Wait(10) ' Necessary for message to show up properly
    LCDMsg_SetStr(msg,"Script running")
end sub

private sub Initialize()
    setup()
    ret = check_compat()
    if ret=0 then
        Wait(100)
        LCDMsg_SetStr(msg,"Not compatible!")
    end if
    if ret=1 then
        Wait(100)
        palette_mod()
        LCDMsg_SetStr(msg,"Overlay disabled!")
    end if
    Wait(500) ' Keep last message visible for 0.5s
end sub

Save it as extend.m in the root directory of the card. The card should be prepared to run scripts.
Switch on the camera in playback mode and press SET. If the script does what is intended, the overlay should be mostly clean when you switch the cam to any shooting mode.
Some parts of the overlay can still be shown, for example I get a square rectangle in the top left when focusing in Auto mode (the background of the 'mode icon'). This square rectangle gets reset when switching modes (same in CHDK itself when clean overlay is enabled).
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: G3 X 1.00C FW Dump
« Reply #18 on: 11 / May / 2020, 16:06:06 »
Quote from: ranma on 11 / May / 2020, 07:03:54
So I'm still having issues with the live view crashing in particular in 1080p mode over HDMI, maybe because CHDK is taking up too much memory or is causing some subtle timing issue somewhere. It works for a while, but usually crashes within a minute or so.
You're not providing a lot of details (firmware dump, source, romlog), so I'm just having a guess. Newer models have the overlay buffers located at the end of physical RAM. If you happen to draw outside them, there's a chance you'll overwrite the start of RAM (camera has 512MB of RAM, it's mirrored above 0x20000000 and 0x60000000).

I also noticed that you're working on the 110e firmware which is not the latest. The latest official firmware is the recently released 120a (1.2.0). I'd suggest working on that to avoid having to maintain multiple ports.
Logged
*

Offline ranma

  • *
  • 7
Re: G3 X 1.00C FW Dump
« Reply #19 on: 11 / May / 2020, 18:11:20 »
Quote from: srsa_4c on 11 / May / 2020, 16:06:06
You're not providing a lot of details (firmware dump, source, romlog), so I'm just having a guess. Newer models have the overlay buffers located at the end of physical RAM. If you happen to draw outside them, there's a chance you'll overwrite the start of RAM (camera has 512MB of RAM, it's mirrored above 0x20000000 and 0x60000000).

Would be interesting to set the unused MPU region as a guard area after the ram. At least the exception handlers won't get overwritten easily since they are in ATCM, which is not mirrored, so the first 4K in the mirror you can actually scribble into without consequences AFAICS. :)

I've set "ARAM" to a different area and enabled CHDK from ARAM, which _seems_ to have resolved the instability issue (needs more testing).
This is an apparently unused memory region I found between 0x00c16b90 - 0x00dfffff, which I think is probably owned by one of the Xtensa cores, given that 0xc00000 area contains "Dry[Zico]" and 0xe00000 area contains references to Xtensa regs "EPC" and "EXCVADDR".
To test memory usage I wrote the whole RAM with 0xdeadbeef on startup and then dumped the ram later over ptp after exercising camera features including video, though it would be good to double-check where the Xtensa heap boundaries are.

Quote from: srsa_4c on 11 / May / 2020, 16:06:06
I also noticed that you're working on the 110e firmware which is not the latest. The latest official firmware is the recently released 120a (1.2.0). I'd suggest working on that to avoid having to maintain multiple ports.

Yeah, I should update to 120a, so far I think I've never upgraded since I bought the camera. :)
In any case I wanted to be sure I can run code (also as FI2) before upgrading.
Logged
Pages: 1 [2] 3   Go Up
« previous next »
 

Related Topics