Adding new cameras, applying patches into trunk (with source code prepared) - page 161 - General Discussion and Assistance - CHDK Forum
supplierdeeply

Adding new cameras, applying patches into trunk (with source code prepared)

  • 1611 Replies
  • 419578 Views
*

Offline blackhole

  • *****
  • 663
  • A590IS 101b
    • Planetary astrophotography
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1600 on: 21 / November / 2018, 12:06:21 »
Advertisements
Source code for sx420is, firmware version 100a.

*

Offline reyalp

  • ******
  • 11898
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 11898
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1602 on: 21 / November / 2018, 23:55:48 »
Source code for sx420is, firmware version 100a.
Checked in, trunk 5124. I left it disabled in the autobuild, let me know if you think it should be enabled.

Thanks for all the contributions :)
Don't forget what the H stands for.

*

Offline blackhole

  • *****
  • 663
  • A590IS 101b
    • Planetary astrophotography
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1603 on: 24 / November / 2018, 18:01:25 »
SX420is_100a:
changed status from PREALPHA to ALPHA
CAM_ACTIVE_AREA customized to the right dimensions
CAM_AV_OVERRIDE_IRIS_FIX and the associated changes
WIFI button as an option for ALT
removed CAM_SD_OVER_IN_AF, the camera allows SD override only when AFL or MF is set

I think we can add this camera to autobuild.
The CHDK for this camera has been used for several months, and we have no problems with it.

The same goes for sx610hs, test build is dawnloaded 89 times without reporting problems so we can assume that everything works well.


*

Offline blackhole

  • *****
  • 663
  • A590IS 101b
    • Planetary astrophotography
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1604 on: 24 / November / 2018, 18:02:27 »
Source code for sx430is, firmware version 100b.

*

Offline reyalp

  • ******
  • 11898
Re: Adding new cameras, applying patches into trunk (with source code prepared)
« Reply #1605 on: 24 / November / 2018, 20:54:55 »
Source code for sx430is, firmware version 100b.
Checked in, trunk 5127. Note I disabled FI2 building in makefile.inc until I can verify the autobuild has the right key. You'll need to comment out the override OPT_FI2= line if you want to build an FI2 locally.

edit:
Autobuild is not enabled for this port at the moment anyway, but I don't want to forget and have it break the build.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3107
    • Photos
Patch for finsig_thumb2 & capdis to work with capstone version 4.


Tested with unpatched version of capstone 4.0.1 library on MacOS and Mint LMDE3 - all stubs rebuild ok (although I can't test SX60HS 1.00h since I don't have the FW dump).
Also tested capdis with extracting G5X code from the FW dump - seems to work ok.



Should still build and work for capstone 3 as well.


Phil.

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)

*

Offline reyalp

  • ******
  • 11898
Patch for finsig_thumb2 & capdis to work with capstone version 4.

Tested with unpatched version of capstone 4.0.1 library on MacOS and Mint LMDE3 - all stubs rebuild ok (although I can't test SX60HS 1.00h since I don't have the FW dump).
Also tested capdis with extracting G5X code from the FW dump - seems to work ok.
Thanks for doing this. Checked in, trunk 5169

On windows, I was able to use the pre-built 32 bit libraries from http://www.capstone-engine.org/download.html but only linking to the import library, like
Code: [Select]
CAPSTONE_TOOLS_LINK=-Ld:/devel/capstone-4.0.1-win32 -lcapstone_dll
CAPSTONE_TOOLS_INC=-Id:/devel/capstone-4.0.1-win32/include/capstone
msys and msys2 compilers didn't like the supplied static library. This means the DLL has to be on the path.

I compared output of the unpatched version with the patched version, with both capstone 3 and 4. No difference for any model I have dumps for. I also did full disassembly of g7x and sx710, and got effectively identical output. On sx710, a few literal pools where garbage previously  disassembled as ssat/usat failed to disassemble instead. All other differences were due CHDK code/stubs changes since the last time I did a full disassembly.

IMO, we should drop capstone 3 support fairly quickly, since it requires a source patch and there's a risk of getting different output from things like the differences in handling invalid code.

I'll post an SX60HS 1.00h dump in the dumps thread if I can't find an existing link.
Edit: one here https://chdk.setepontos.com/index.php?topic=12532.msg136787#msg136787

« Last Edit: 26 / April / 2019, 01:23:03 by reyalp »
Don't forget what the H stands for.


*

Offline philmoz

  • *****
  • 3107
    • Photos
Patch for live view for review.
This removes the calls to malloc & free for the header/desc buffers and the memcpy for the palette data. The palette data is sent with a seperate data_send call from the original palette memory buffer.
This reduces the risk of heap fragmentation when using LV in chdkptp (it gets called a lot).
There does not seem to be any negative impact from adding another send_data call on cameras with 256 palette entries; but I'm not sure of the impact on cameras with only 16 palette entries (64 bytes).

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)

*

Offline reyalp

  • ******
  • 11898
This removes the calls to malloc & free for the header/desc buffers and the memcpy for the palette data.
That's a good idea.
Quote
There does not seem to be any negative impact from adding another send_data call on cameras with 256 palette entries; but I'm not sure of the impact on cameras with only 16 palette entries (64 bytes).
I'd expect it's negligible compared to the time required to send the actual framebuffer.

I wondered if stack size might be a concern, since the header is moderately large (36 bytes per buffer desc, plus 32 for header), but PTPSession seems to get a pretty generous size: 0x1000 on a540, 0x1800 on g7x and the stock PTP handlers are pretty complicated.

edit:
I tried it on a540 (16 entry palette) and it seems to be fine.
« Last Edit: 11 / May / 2019, 22:18:13 by reyalp »
Don't forget what the H stands for.

 

Related Topics