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

Porting a camera sx530hs

  • 300 Replies
  • 150476 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: Porting a camera sx530hs
« Reply #190 on: 24 / May / 2016, 14:14:07 »
Advertisements
Hello, just a simple question. I have CHDK on my sx530hs, working fine but I cannot load any scripts or even see files on my SD card (Kingstone 64GB SDXC Class 10 uhs 1). Any suggestions? http://imgur.com/a/1WX5t
That's now the second report about a misdetected exFAT card.
Please do the following:

Enable "Miscellaneous stuff -> Disable long filename support" in the CHDK menu.
Copy this
Code: [Select]
print(call_func_ptr(0xff030214,0))one line script to a plain ASCII file with .lua extension and execute it on camera (enable "Miscellaneous stuff -> Enable Lua native calls" before). On an exFAT card, it should print '4'. You'll likely see some other number, can you tell me which one?

Edit:
anyone else having this issue on cards formatted as exFAT?
« Last Edit: 24 / May / 2016, 14:16:00 by srsa_4c »

Re: Porting a camera sx530hs
« Reply #191 on: 24 / May / 2016, 14:34:41 »

After I did the 'Disable long filename support' step, I could open any file from my SD card, so thank you. When I tried creating the .lua file with code in it, the result number is 4.

Re: Porting a camera sx530hs
« Reply #192 on: 24 / May / 2016, 14:43:56 »
 [ deleted ]
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: Porting a camera sx530hs
« Reply #193 on: 24 / May / 2016, 14:46:09 »
After I did the 'Disable long filename support' step, I could open any file from my SD card, so thank you. When I tried creating the .lua file with code in it, the result number is 4.
Thanks. Keep that option ticked while using the test build.


For developers:
Weak functions strike again. This port (sx520/530) is cursed somehow.
This is the CHDK function that should detect the filesystem type:
Code: [Select]
0060e8e8 <_get_fstype>:
  60e8e8: e3a00000 mov r0, #0
  60e8ec: e12fff1e bx lr
No wonder it doesn't work. No such problems on my ixus150 port.

*

Offline blackhole

  • *****
  • 946
  • A590IS 101b
    • Planetary astrophotography
Re: Porting a camera sx530hs
« Reply #194 on: 24 / May / 2016, 16:00:28 »
After I did the 'Disable long filename support' step, I could open any file from my SD card, so thank you. When I tried creating the .lua file with code in it, the result number is 4.
Thanks. Keep that option ticked while using the test build.


For developers:
Weak functions strike again. This port (sx520/530) is cursed somehow.
This is the CHDK function that should detect the filesystem type:
Code: [Select]
0060e8e8 <_get_fstype>:
  60e8e8: e3a00000 mov r0, #0
  60e8ec: e12fff1e bx lr
No wonder it doesn't work. No such problems on my ixus150 port.
Never end of surprises.
Can I help you somehow?

*

Offline srsa_4c

  • ******
  • 4451
Re: Porting a camera sx530hs
« Reply #195 on: 24 / May / 2016, 19:04:15 »
Never end of surprises.
Can I help you somehow?
I can't compile a correct binary for sx530 or sx520. I'm always getting the weak _get_fstype() function from platform/generic/wrappers.c in the final main.bin binary (above disassembly shows what it looks like when compiled).

What I have tried so far:
- compilation from freshly downloaded source
- on Linux, I compiled with eabi 4.8.3 and 4.9.3 toolchains (from https://launchpad.net/gcc-arm-embedded ) and also with arm-elf 4.6.4
- on Vista, I used the eabi 4.9.3 toolchain from the above site, also tried using the new GUI with the 4.9.3 toolchain (downloaded separately from the chdk-de server)

Note that both OS on my machine is 32 bit. reyalp and philmoz have not been able to reproduce this kind of issue (both of them are using 64 bit OSes though).

So, try making a usable build. You need to compile using the command line because it appears the new GUI cleans everything when it finishes building. Locate _get_fstype() in platform/sx530hs/sub/100c/main.bin.dump. If it looks like the above snippet, the build is incorrect.

*

Offline blackhole

  • *****
  • 946
  • A590IS 101b
    • Planetary astrophotography
Re: Porting a camera sx530hs
« Reply #196 on: 25 / May / 2016, 15:48:23 »
Quote
So, try making a usable build.
I've checked all my machines with different OS,Windows XP 32-bit,Windows 7 32-bit,Windows 7 64-bit,but I always get incorrect build.
I used arm-elf 4.5.1 and eabi 4.8.4 and 4.9.3 toolchains.

*

Offline reyalp

  • ******
  • 14126
Re: Porting a camera sx530hs
« Reply #197 on: 25 / May / 2016, 16:52:02 »
Quote
So, try making a usable build.
I've checked all my machines with different OS,Windows XP 32-bit,Windows 7 32-bit,Windows 7 64-bit,but I always get incorrect build.
I used arm-elf 4.5.1 and eabi 4.8.4 and 4.9.3 toolchains.
Turns out this one is a bug in the current CHDK code, affecting all ports. The sigfinder generates NHSTUBS, which are actually weak (for historical reason). So both the default and the sig finder function are weak, and which one wins is unspecified.

I'm not sure what the simplest workaround is, maybe a camera.h define, or CAM_DRYOS_REL conditional.

I don't think this is related to the vid_get_bitmap_active_palette issue is related, but I might have missed something.

On the broader issue:
IMO, sigfinder matches should be hard, and overrides should be handled in some other way. The sigfinder already parses stubs_entry_2.s and doesn't generate entries that appear there, so you might be able to use a stubs_entry_2 entry something like

NHSTUB(foo,my_special_foo)

(or maybe a specific macro for it)

edit: The suggestion above isn't applicable to get_fstype though, because in that case we want to provide a default when the sig finder doesn't find anything.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: Porting a camera sx530hs
« Reply #198 on: 25 / May / 2016, 19:54:02 »
Turns out this one is a bug in the current CHDK code, affecting all ports.
:-[ Thanks for finding that. Multiple mistakes of mine (I have even worked on those macros and posted a question about their naming, but forgot to check when I did the long filename related stuff).

Quote
I'm not sure what the simplest workaround is, maybe a camera.h define, or CAM_DRYOS_REL conditional.
get_fstype is missing on DryOS r31 and older cams. The only (supported) exception is the sx120, which also doesn't have it. The sx120 platform_camera.h already has this:
Code: [Select]
//#define CAM_DRYOS_2_3_R39 1 // Don't define this - even though cam is R39 is still needs old CHDK codeSo, I guess we could just use #ifdef CAM_DRYOS_2_3_R39 in platform/generic/wrappers.c .

Quote
On the broader issue:
IMO, sigfinder matches should be hard, and overrides should be handled in some other way. The sigfinder already parses stubs_entry_2.s and doesn't generate entries that appear there,
If parsing of manual stubs files is working reliably, then I guess that would work. But, developers should then remember to re-generate stubs when overriding some of them manually.

*

Offline reyalp

  • ******
  • 14126
Re: Porting a camera sx530hs
« Reply #199 on: 26 / May / 2016, 00:15:33 »
get_fstype is missing on DryOS r31 and older cams. The only (supported) exception is the sx120, which also doesn't have it. The sx120 platform_camera.h already has this:
...
So, I guess we could just use #ifdef CAM_DRYOS_2_3_R39 in platform/generic/wrappers.c
Sounds OK to me.

Quote
If parsing of manual stubs files is working reliably, then I guess that would work. But, developers should then remember to re-generate stubs when overriding some of them manually.
If there both hard, having it defined in two places should trigger a link error.
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal