Porting a camera sx530hs

srsa_4c

4451

Re: Porting a camera sx530hs

« Reply #190 on: 24 / May / 2016, 14:14:07 »

Advertisements

Quote from: itsdzey on 24 / May / 2016, 13:42:54

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 »

Logged

itsdzey

2

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.

Logged

waterwingz

12139

Re: Porting a camera sx530hs

« Reply #192 on: 24 / May / 2016, 14:43:56 »

[ deleted ]

Logged

Ported : A1200 SD940 G10 Powershot N G16

srsa_4c

4451

Re: Porting a camera sx530hs

« Reply #193 on: 24 / May / 2016, 14:46:09 »

Quote from: itsdzey 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.

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.

Logged

blackhole

940
A590IS 101b

Re: Porting a camera sx530hs

« Reply #194 on: 24 / May / 2016, 16:00:28 »

Quote from: srsa_4c on 24 / May / 2016, 14:46:09

Quote from: itsdzey 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.
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 lrNo wonder it doesn't work. No such problems on my ixus150 port.

Never end of surprises.
Can I help you somehow?

Logged

http://astrofoto.pondi.hr

srsa_4c

4451

Re: Porting a camera sx530hs

« Reply #195 on: 24 / May / 2016, 19:04:15 »

Quote from: blackhole on 24 / May / 2016, 16:00:28

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.

Logged

blackhole

940
A590IS 101b

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.

Logged

http://astrofoto.pondi.hr

reyalp

14082

Re: Porting a camera sx530hs

« Reply #197 on: 25 / May / 2016, 16:52:02 »

Quote from: blackhole 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.

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.

Logged

Don't forget what the H stands for.

srsa_4c

4451

Re: Porting a camera sx530hs

« Reply #198 on: 25 / May / 2016, 19:54:02 »

Quote from: reyalp on 25 / May / 2016, 16:52: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.

Logged

reyalp

14082

Re: Porting a camera sx530hs

« Reply #199 on: 26 / May / 2016, 00:15:33 »

Quote from: srsa_4c on 25 / May / 2016, 19:54:02

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.

Logged

Don't forget what the H stands for.