G7X II - need help finding led details. - page 4 - General Discussion and Assistance - CHDK Forum

G7X II - need help finding led details.

  • 31 Replies

Online philmoz

  • *****
  • 3332
    • Photos
Re: G7X II - need help finding led details.
« Reply #30 on: 25 / May / 2019, 08:16:08 »
The '-x W' option worked for the G5X; but no luck with the G7X2 (gives the "Update file error" message).
The checksum seems to be word based, so using '-x W' is correct.

Turns out, parts of the fi2 validation process can be run individually. In sub_E04B3DBC, these are functions that get the open()'d FI2 file's descriptor as argument.
Functions with a single argument: sub_E052671E, sub_E05267F4, sub_E0526794
Function with 3 args: sub_E05266B8, see usage in disassembly.
Can you check the return values from these functions?

You can do that from Canon Basic, either printing the result on screen or to a file. The exec eventproc can be used to call a firmware function, similarly to "our" call_func_ptr.
Correct LCDMsg usage can be found in https://chdk.fandom.com/wiki/Canon_Basic/Scripts/Dumper#Improved_universal_dumper
The exec, Open, Close eventprocs are registered by System.Create.

Thanks for the suggestions. Turns out the firmware boot does work on the G7X2 - I had a mistake in the script I was using to copy files to the SD card so ended up with the wrong file.

Anyway the firmware boot behaves exactly the same as diskboot.bin - both my current boot code and your loader tests.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)


Offline srsa_4c

  • ******
  • 4426
Re: G7X II - need help finding led details.
« Reply #31 on: 05 / October / 2019, 05:32:19 »
Early in the startup (just after stdio setup) it calls a function at 0xe051e07c which calls 0xe04f0d9c (this is FW 1.01a).
The store operation to 0xc1001f00 hangs the camera - I can blink the LED before this instruction; but not after.
Newest theory about this.
sub_e051e07c takes the second core from "parking" state. If I'm not wrong, it is set to resume running at the address of the diskboot (0x8000), as thumb. This address is stored on stack (could be normal stack) of the previously running OS. edit2: Doesn't matter, it is already in a register while the cpu waits.
And guess what happened to the code at 0x8000 by the time this happens...

The updater obviously doesn't overwrite itself, so this method works there.

Unblocking core1 works from loader (both cores blink), but not from platform (with ldr pc written to 0x8000 for core1). Todo: why? edit: Cause was an unnoticed indirect jump in boot().

Core1 seems correctly freed when
- it is unlocked in loader,
- redirected to a temporary loop copied into a free spot in TCM
- and later freed again.
That core is then available (it can start the Startup task if the CreateTask is replaced with the core-specific CreateTask variant). Cam still powers off later (worth to mention that I have a different camera, so YMMV).
« Last Edit: 07 / October / 2019, 14:06:02 by srsa_4c »


Related Topics