SX60HS Porting - page 2 - DryOS Development - CHDK Forum
supplierdeeply
« previous next »
Pages: 1 [2] 3 4 5 6 7 ... 92   Go Down

SX60HS Porting

  • 915 Replies
  • 211908 Views
*

Offline srsa_4c

  • ******
  • 4001
Re: SX60HS Porting
« Reply #10 on: 01 / September / 2015, 18:53:22 »
Advertisements
Quote from: iax on 01 / September / 2015, 18:40:29
If I know uncomment CreateTask_spytask, camera crashes inside the conf_restore() function call in /core/main.c. Didn't have the time yet to understand what's happening there.
Could be file operation related. Other than double checking the stubs, be sure to look at the open/write/close fopen/fwrite/fclose wrappers in platform/generic/wrappers.c to see what else you need (a fw semaphore variable address and semaphore fuctions).
Until you get CHDK running you can use this Canon Basic script to retrieve the romlogs.

Quote
I was hoping to be able to pull up the CHDK GUI, leaving out for now capt_seq_task and task_ExpDrv, would this be possible?
I think so, replacing capt_seq, expdrv, movie, filewrite is not essential.
Logged
*

Offline iax

  • *
  • 45
Re: SX60HS Porting
« Reply #11 on: 02 / September / 2015, 18:39:21 »
I'm stuck with fileIOSemaphore, precisely camera hangs at

_TakeSemaphore(fileio_semaphore,timeout)

inside of int takeFileIOSemaphore() (wrappers.c), while reading font files.

In my stubs I have:

NHSTUB(TakeSemaphore, 0xFC2CF39C) // Arm, found in 0xFC065F96 (similar to 0xFC055294 in the 280-102b)

and

DEF(fileio_semaphore, 0x00013294) // Found @0xFC06E5B4 (similar to 0xFC05CCA0 in the 280-102b)

since there are no other intermediate level calls, at least one of the two stubs should be wrong but I'm unable to spot the mistake...Value of timeout seems irrelevant according to few tests I've done.

Any suggestion here? Thanks for the fantastic help.
« Last Edit: 02 / September / 2015, 18:45:38 by iax »
Logged
*

Offline srsa_4c

  • ******
  • 4001
Re: SX60HS Porting
« Reply #12 on: 02 / September / 2015, 19:00:22 »
I'll take a look and update this post once done.
Logged
*

Offline antwtna

  • *
  • 13
Re: SX60HS Porting
« Reply #13 on: 03 / September / 2015, 08:46:04 »
Hi,
did you try what srsa_4c suggested about retrieving the romlogs?
This helps debugging a lot if the processor goes in fault, and helped me with some wrong stubs adresses (that had to be ARM but that I wrote initially as thumb).

I am trying to port chdk in the sx700 starting from sx280(find the thread here), but I am facing some file io related issues as well. The symptoms are different from yours but the cause may be similar, also because I may have different task and check enabled or disabled in the boot.
So also in my stubs there could be an issue with "TakeSemaphore" or "fileio_semaphore". I verified both of them and the addresses seem ok.
I know that this may be a silly question, but still... I have a doubt about the way the "TakeSemaphore" is called, since in the assembly I see blx <label> instructions to call it(so that the processor state switches from thumb to ARM). In the NHSTUB in the "include\stubs_asm.h" I see:

Code: [Select]
#define NHSTUB(name, addr)\
    .globl _##name ;\
    .weak _##name ;\
    _##name: ;\
    .code 16 ;\
    ldr.w pc, [pc, #0] ;\
    .long addr
Shouldn't that be a .code32 instead of .code16 since we are calling an ARM function?

Regards,
A.
« Last Edit: 03 / September / 2015, 08:55:02 by antwtna »
Logged
*

Offline srsa_4c

  • ******
  • 4001
Re: SX60HS Porting
« Reply #14 on: 03 / September / 2015, 11:09:29 »
The TakeSemaphore stub and the fw variable both look correct in both fw.
Could it be that the firmware now uses the semaphore differently...? The semaphore init function in sx700 seems identical to the sx280 one.

Try the following workaround:
add #define CAM_IS_VID_REC_WORKS 1 to platform_camera.h (even if it's not true).
replace the !conf.allow_unsafe_io checks in platform/generic/wrappers.c to make the file io functions succeed. (You need this since you probably can't reach the CHDK menu to enable that conf setting.)

Quote from: antwtna on 03 / September / 2015, 08:46:04
Shouldn't that be a .code32 instead of .code16 since we are calling an ARM function?
The blx <label> instruction does switch between Thumb and ARM state. The blx <register> form continues according to the address (bit0, thumb bit) stored in <register>. The ldr PC, instruction also respects the thumb bit and switches between ARM and Thumb if needed.
So, code16 is required because CHDK code is Thumb, the ldr instruction has to be Thumb too.
« Last Edit: 03 / September / 2015, 11:12:11 by srsa_4c »
Logged
*

Offline iax

  • *
  • 45
Re: SX60HS Porting
« Reply #15 on: 03 / September / 2015, 16:43:12 »
Quote
add #define CAM_IS_VID_REC_WORKS 1 to platform_camera.h (even if it's not true).
replace the !conf.allow_unsafe_io checks in platform/generic/wrappers.c to make the file io functions succeed.

yes, definitely forcing a return 0 in takeFileIOSemaphore() and your suggestions (I've just added a force_allow_unsafe_io = 1 and changed all conditions to !conf.allow_unsafe_io && !force_allow_unsafe_io) does the trick, thank you.

Trying to move forward now...
Logged
*

Offline antwtna

  • *
  • 13
Re: SX60HS Porting
« Reply #16 on: 04 / September / 2015, 05:53:36 »
Good for you! That didn't work for my sx700hs port.

Are you trying to use chdkptp? In this case can you read memory(rmem) and see the correct file tree in the file tab?
Logged
*

Offline srsa_4c

  • ******
  • 4001
Re: SX60HS Porting
« Reply #17 on: 04 / September / 2015, 14:28:15 »
I still have no clue what could be wrong with file I/O and that semaphore.

This issue will have to be debugged, because using "vanilla" firmware file IO functions can cause random crashes.
The plan is:
- get a nice big unused RAM area somewhere
- patch TakeSemaphore/GiveSemaphore to make them log debug data when they are working on the fileio semaphore
- write the log to a file or retrieve it through PTP
- the debug data is to include the task name, timestamp, caller's address. Perhaps that's enough.

So, if any of you has working file IO and is willing to help, don't forget to remind me.
Logged
*

Offline iax

  • *
  • 45
Re: SX60HS Porting
« Reply #18 on: 05 / September / 2015, 03:53:28 »
I'm happy to help here, I can have a try. About the steps you suggest I'm not sure how to do the first: how do you recommend to locate the RAM area where to log?

About my current progress, I'm still not able to pull the GUI up even if the main loop apparently is working, so apparently I'm not too far. Not really sure how to get the correct values for CAM_BITMAP_WIDTH/HEIGHT and CAM_SCREEN_WIDTH/HEIGHT, what's the typical way of doing this?

I'ts likely I won't be able to work on this the next couple of week though.
Logged
*

Offline srsa_4c

  • ******
  • 4001
Re: SX60HS Porting
« Reply #19 on: 05 / September / 2015, 09:28:57 »
Quote from: iax on 05 / September / 2015, 03:53:28
I'm happy to help here, I can have a try. About the steps you suggest I'm not sure how to do the first: how do you recommend to locate the RAM area where to log?
The AdditionAgentRAM memory area should be available. It starts at 0x6ce000 and is 0x22000 bytes long. The task stuff is (ARM wrapper addresses):
0xfc2cf18c int get_self_task_id(void)
0xfc2cf19c void get_task_control_block(int id, char *buffer)
buffer needs to be adequate sized, I don't know how long the returned struct is, use 0x100 for example. The task name pointer is at the +0x30 offset.
Above can be found in the standard assert routine: 0xfc0e4734, which can be found by searching for "Task ID: %d" in the disassembly.

Quote
About my current progress, I'm still not able to pull the GUI up even if the main loop apparently is working, so apparently I'm not too far. Not really sure how to get the correct values for CAM_BITMAP_WIDTH/HEIGHT and CAM_SCREEN_WIDTH/HEIGHT, what's the typical way of doing this?
See info in platform/sx280hs/lib.c update_screen_dimensions(). If the LCD and EVF is below 1Mpoints resolution, the buffer is probably 640x480.
« Last Edit: 05 / September / 2015, 09:30:42 by srsa_4c »
Logged
Pages: 1 [2] 3 4 5 6 7 ... 92   Go Up
« previous next »
 

Related Topics