Porting a camera sx530hs - page 13 - DryOS Development - CHDK Forum  

Porting a camera sx530hs

  • 300 Replies
  • 149096 Views
*

Offline blackhole

  • *****
  • 945
  • A590IS 101b
    • Planetary astrophotography
Re: Porting a camera sx530hs
« Reply #120 on: 17 / April / 2016, 19:34:48 »
Advertisements
Quote
For sx530hs 100c, we can use

!con:call_function(0xFF21DE30,0)

to turn off, 1 to turn on. In my previous testing, turning off and attempting to access the SD card worked after some delay, so it's possible this causes the firmware to reset it's disk subsystem.
Quote
Until then, try reyalp's recent suggestion:
I tried, unfortunately has no effect.

*

Offline blackhole

  • *****
  • 945
  • A590IS 101b
    • Planetary astrophotography
Re: Porting a camera sx530hs
« Reply #121 on: 20 / April / 2016, 18:53:11 »
I have a fix for SD overrides and DFS.
I doubt, to add to the same patch and changes in boot.c for the usual start,
Code: [Select]
*(int*)(0x2cf4+0x8) = (*(int*)0xc022f48c) & 0x80000 ? 0x400000 : 0x200000;or  for now leave out this change?

edit:
added a patch with all the changes
« Last Edit: 20 / April / 2016, 19:13:54 by blackhole »

*

Offline srsa_4c

  • ******
  • 4451
Re: Porting a camera sx530hs
« Reply #122 on: 20 / April / 2016, 19:34:11 »
added a patch with all the changes
I think including the start "fix" is OK (it allows starting in rec mode, no-one knows the real solution at this time anyway).

Attached are debug versions of 2 files (based on the old source, without your patch).
Build instruction is the same as last time (PRIMARY.BIN needed for modifying stubs_entry.S).

I'm attempting to wrap the firmware's Open(), Read(), Write(), Close() functions (for CHDK only). The SD card related functions also remain wrapped. Logs are gathered in the same memory buffers as last time.

Can you do this:
- build a debug version of CHDK (I'd recommend keeping a separate source tree, so it doesn't mix up with the work you're doing)
- copy the diskboot.bin and modules to both cards (good and bad) - it's important to have the same modules on the cards
- test procedure for both cards:
 - start the cam in playback mode with USB connected
 - in CHDK menu, attempt to start the file browser (and close it immediately on the good card)
 - dump the buffers over PTP

(I did not test this version, I hope it's working)

*

Offline blackhole

  • *****
  • 945
  • A590IS 101b
    • Planetary astrophotography
Re: Porting a camera sx530hs
« Reply #123 on: 20 / April / 2016, 20:16:12 »
Files are attached.


*

Offline srsa_4c

  • ******
  • 4451
Re: Porting a camera sx530hs
« Reply #124 on: 21 / April / 2016, 11:23:00 »
Files are attached.
Thanks.
Looks odd.
In the 'bad' case:
First, I see no attempt to load the file browser module. But I do see the Lua module loading.
Second. Files opened for reading appear to open correctly and can be read (I see actual file content and read() returns the number of bytes read). Write() fails and returns -1.
Close also returns -1 (which means error), but the next file opens correctly and gets the same file descriptor.
Since I don't think any part of code checks for the value returned by close(), reading should - theoretically - be working.

It could be that other file related functions (stat, opendir, etc) also misbehave and that is causing the general impression that no file operations work.

Plan for the next step is: making a copy of the firmware's Write() or Close() function and trying to find out where it fails.

About your patch: it appears that capt_seq.c was not regenerated (make run-code-gen) after editing capt_seq_hdr.c. You may have edited capt_seq.c afterwards.

*

Offline blackhole

  • *****
  • 945
  • A590IS 101b
    • Planetary astrophotography
Re: Porting a camera sx530hs
« Reply #125 on: 21 / April / 2016, 16:37:00 »
Quote
Looks odd.
In the 'bad' case:
First, I see no attempt to load the file browser module. But I do see the Lua module loading.
Second. Files opened for reading appear to open correctly and can be read (I see actual file content and read() returns the number of bytes read). Write() fails and returns -1.
Close also returns -1 (which means error), but the next file opens correctly and gets the same file descriptor.
Since I don't think any part of code checks for the value returned by close(), reading should - theoretically - be working.

It could be that other file related functions (stat, opendir, etc) also misbehave and that is causing the general impression that no file operations work.

Plan for the next step is: making a copy of the firmware's Write() or Close() function and trying to find out where it fails.
Attached are the new dumps with a bad card.
Now I started a file browser (with the USB connected) before starting chdkptp. If I try to run a file browser, with running chdkptp, CHDK menu only briefly flashes and nothing happens.
Quote
About your patch: it appears that capt_seq.c was not regenerated (make run-code-gen) after editing capt_seq_hdr.c. You may have edited capt_seq.c afterwards.
I did not use code-gen.
I'll make it again when I find more time.

*

Offline srsa_4c

  • ******
  • 4451
Re: Porting a camera sx530hs
« Reply #126 on: 21 / April / 2016, 18:02:32 »
Now I started a file browser (with the USB connected) before starting chdkptp. If I try to run a file browser, with running chdkptp, CHDK menu only briefly flashes and nothing happens.
Can you check if there are any error messages visible on the CHDK console, after you do that? Miscellaneous stuff -> Console -> Display last console. No dump needed this time.
Quote
I did not use code-gen.
I'll make it again when I find more time.
Okay, I don't want to force you to learn code_gen scripting too. If your capt_seq.c and boot.c changes are meant to be final, I can make the necessary change.

*

Offline blackhole

  • *****
  • 945
  • A590IS 101b
    • Planetary astrophotography
Re: Porting a camera sx530hs
« Reply #127 on: 21 / April / 2016, 19:08:00 »
Quote
Can you check if there are any error messages visible on the CHDK console, after you do that?
Error visible in CHDK console is:
Fail to load fselect.flt: open error
Quote
Okay, I don't want to force you to learn code_gen scripting too. If your capt_seq.c and boot.c changes are meant to be final, I can make the necessary change.
Thanks.
That's it, I have no intention to change anything more.


*

Offline srsa_4c

  • ******
  • 4451
Re: Porting a camera sx530hs
« Reply #128 on: 23 / April / 2016, 10:51:16 »
added a patch with all the changes
I have added this in changeset 4604.

I have also found a number of issues that might need attention (if you have time, of course).

  • I'm not convinced that the extra delay
    #define PAUSE_FOR_FILE_COUNTER 350
    in capt_seq.c is actually needed. Try commenting it out and see if your DNG files get the corresponding JPEG file's number.
  • I'm also not convinced that the cam has an ND filter. It is currently enabled but setting the CHDK ND override will likely crash the camera due to the missing initialization in init_required_fw_features(). I'd recommend removing
    #define CAM_HAS_ND_FILTER               1
    from platform_camera.h .
  • I think the set_zoom script command needs
    #define CAM_NEED_SET_ZOOM_DELAY            300
    in platform_camera.h to not crash the camera.
  • It would be worth implementing DRAW_ON_ACTIVE_BITMAP_BUFFER_ONLY. The ixus150 port might be useful as an example. I might look into this if requested.
  • Some buttons are not mapped yet, some others appear with incorrect names in kbd.c. Debug display of physw_status values can be enabled by uncommenting the section around
    // debug keymap, KEYS_MASKx, SD_READONLY_FLAG, USB_MASK
    in core/gui_osd.c.
  • Subject distance override is likely untested (scripts/test/mftest.lua)

*

Offline blackhole

  • *****
  • 945
  • A590IS 101b
    • Planetary astrophotography
Re: Porting a camera sx530hs
« Reply #129 on: 24 / April / 2016, 17:41:14 »
Quote
I have added this in changeset 4604.
Thanks.
Quote
Some buttons are not mapped yet, some others appear with incorrect names in kbd.c. Debug display of physw_status values can be enabled by uncommenting the section around
// debug keymap, KEYS_MASKx, SD_READONLY_FLAG, USB_MASK
in core/gui_osd.c.
Yes, KEY_DISPLAY is probably unnecessary, it's the same key as the KEY_DOWN.
Missing KEY_WIFI.
With the above mentioned changes I see something like this:
Code: [Select]
MEM: 0x1e3c1e3c
PS1: 0xffdf9
PS2: 0
PS3: 44003f4
When I press a button WIFI, PS3: 0x44003f4 was changed to PS3: 0x44001f4.
I do not know how to interpret these changes.

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal