A2300 porting thread - DryOS Development - CHDK Forum
« previous next »
Pages: [1] 2 3 4 5 6 ... 8   Go Down

A2300 porting thread

  • 70 Replies
  • 41781 Views
*

Offline nafraf

  • *****
  • 1308
A2300 porting thread
« on: 16 / July / 2012, 14:04:13 »
Advertisements
Hi,
I'll have this camera for a few weeks, but I'll try to port as much as I could.

Dump is available at box.net/chdk repository.

Code: [Select]
// Camera info:
//   DRYOS R50 (DRYOS version 2.3, release #0050)
//   Firmware Ver B1.01
//   Canon PowerShot A2300

Tools used: chdkpt and arm-elf-gcc-4.6.0 for linux.

LED Addresses:
#define LED_GREEN      0xC0220120 //LED on the back of the camera
#define LED_AF         0xC0223030 //Autofocus LED

I'm using SX260HS and ELPH310 as reference port.

The SX260HS port was choosen because it is a Release #0050 port, but it uses a Digic V.
ELPH130 (IXUS230) uses DryOS Release #0049, but the processor is a Digic IV, the same used for the A2300. Looking the firmware, specially taskcreate_Startup_my(), the port of ELPH310 seems to be more similar to our objective.

The A2300 seems to be one of the first powershot with Release #0050 being ported, and I'm having problems with boot.

I used a LED blinking to follow boot process, it is going to task_Startup_my() beginning, but after that camera freezes. In task_Startup_my() I'm calling the original taskcreate_PhySw() and taskHook() contents is commented.  I expected to see camera starting normally, turning on LCD, but after LED blinking nothing happens, or am I wrong?  I commented calls to LED blinking function, camera freezes too.

Debugging inside assembly code of task_Startup_my() (using LED blinking), I could see that camera is going to line where StartFactoryModeController is called, but it stops there.

Well, what could I do? Do you have any suggestions?  The boot.c file is in attachment.

Thanks.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: A2300 porting thread
« Reply #1 on: 16 / July / 2012, 14:39:48 »
I have no idea, but a few things to try:
- does the boot process get further when you disable that factory mode related call?
- in case the logging is already started, the camera may have saved a romlog, try http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Romlog
Logged
*

Offline nafraf

  • *****
  • 1308
Re: A2300 porting thread
« Reply #2 on: 16 / July / 2012, 17:12:09 »
Disabling the function related to factory mode the behavior is the same.
No romlog was generated, I'll continue testing to get a ROMLOG. 
Thanks
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: A2300 porting thread
« Reply #3 on: 16 / July / 2012, 19:41:51 »
Quote from: nafraf on 16 / July / 2012, 14:04:13
I'll have this camera for a few weeks, but I'll try to port as much as I could.
Actually having the camera will make things a whole lot easier than your last project !

Quote from: nafraf on 16 / July / 2012, 14:04:13
Code: [Select]
//   DRYOS R50 (DRYOS version 2.3, release #0050)
Tools used: chdkpt and arm-elf-gcc-4.6.0 for linux.
A word of caution.   I have not looked at how CHDK-PT behaves with the new cameras.  Apparently these cameras relocate some code from ROM to RAM at startup and this might confuse CHDK-PT.  And there was at least one report in the last six months about it getting a target address wrong ( B  sub_FFFF0000 where FFFF0000 was the wrong address).   Not sure if its related.

I'll have to go back and look at that I guess now that I seem to be out of orphan ports to clean up and submit.   At least for a while....

Quote from: nafraf on 16 / July / 2012, 17:12:09
No romlog was generated, I'll continue testing to get a ROMLOG. 
You are most likely crashing before DryOS actually gets running so there is no way it could be producing a ROMLOG.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline srsa_4c

  • ******
  • 4451
Re: A2300 porting thread
« Reply #4 on: 16 / July / 2012, 21:11:33 »
@nafraf
Once you get over this booting issue and want to try something new, I'd suggest you to modify the CreateTask code in RAM to get rid of the current TaskHook hack. CreateTask's key parameters are known, it should't be too complicated to find and replace the needed tasks from there. You can ask for details if you're unsure, how. (Hopefully all needed tasks are started by this function...)
Logged
*

Offline nafraf

  • *****
  • 1308
Re: A2300 porting thread
« Reply #5 on: 16 / July / 2012, 21:18:10 »
Quote from: waterwingz on 16 / July / 2012, 19:41:51
Actually having the camera will make things a whole lot easier than your last project !
You are right!! but until now I haven't seen CHDK logo, only blinking LEDs :)

Quote from: waterwingz on 16 / July / 2012, 19:41:51
Quote from: nafraf on 16 / July / 2012, 14:04:13
Code: [Select]
//   DRYOS R50 (DRYOS version 2.3, release #0050)
Tools used: chdkpt and arm-elf-gcc-4.6.0 for linux.
A word of caution.   I have not looked at how CHDK-PT behaves with the new cameras.  Apparently these cameras relocate some code from ROM to RAM at startup and this might confuse CHDK-PT.  And there was at least one report in the last six months about it getting a target address wrong ( B  sub_FFFF0000 where FFFF0000 was the wrong address).   Not sure if its related.
I don't think that it is related, but I'll check the code.
Comparing outputs of chdk-pt and disassembly.pl, It seems that ROM address are generated right.  With RAM addresses, there are some problems like:
Code: [Select]
//RAM Addresses
"    BL     sub_FC3F7A50 \n"   //generated by chdk-pt
"    bl      loc_3f7a50 \n"   //generated by disassembly.pl
I was thinking to report that as a chdk-pt bug.
Logged
*

Offline nafraf

  • *****
  • 1308
Re: A2300 porting thread
« Reply #6 on: 16 / July / 2012, 21:21:21 »
Quote from: srsa_4c on 16 / July / 2012, 21:11:33
@nafraf
Once you get over this booting issue and want to try something new, I'd suggest you to modify the CreateTask code in RAM to get rid of the current TaskHook hack. CreateTask's key parameters are known, it should't be too complicated to find and replace the needed tasks from there. You can ask for details if you're unsure, how. (Hopefully all needed tasks are started by this function...)
Well, I'll need to learn more about CHDK. I have not understood TaskHook hack.  :(
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: A2300 porting thread
« Reply #7 on: 16 / July / 2012, 21:25:38 »
Quote from: nafraf on 16 / July / 2012, 21:21:21
Well, I'll need to learn more about CHDK. I have not understood TaskHook hack.  :(
OK, we can get back to this once you're booting.
What I'm talking about is this:
   *(int*)0x1938=(int)taskHook;
   *(int*)0x193C=(int)taskHook;
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: A2300 porting thread
« Reply #8 on: 16 / July / 2012, 22:21:26 »
Quote from: nafraf on 16 / July / 2012, 21:18:10
Comparing outputs of chdk-pt and disassembly.pl, It seems that ROM address are generated right.  With RAM addresses, there are some problems like:
Code: [Select]
//RAM Addresses
"    BL     sub_FC3F7A50 \n"   //generated by chdk-pt
"    bl      loc_3f7a50 \n"   //generated by disassembly.pl
I was thinking to report that as a chdk-pt bug.
Consider it reported.

At the time CHDK-PT was created,  there was no code that ran in RAM.  So anything it finds in the ROM area is assumed to point to other addresses in the ROM area.  Should not be too hard to fix but I'll have to add a setup option so people can tell CHDK-PT what code relocates and to where.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline nafraf

  • *****
  • 1308
Re: A2300 porting thread
« Reply #9 on: 17 / July / 2012, 19:55:07 »
Now CHDK is booting.  I discovered that the problem was related to the start mode detection.

I'm using values from boot.c file for a4000 written by alvm.  I'm using the same values, but I'm not sure how to find them.  Is there any documentation about that?
Code: [Select]
    if ((*(int*) 0xC0220048) & 1)                   // look at play switch
            *(int*)(0x24B8 + 4) = 0x100000;         // start in play mode
    else
            *(int*)(0x24B8 + 4) = 0x200000;         // start in rec mode

I know that the value 0x24B8 is taken from a procedure called in taskcreate_Startup.  But how to find the button address (0xC0220048)? 
Should I use script as was done to find LED addresses?
Logged
Pages: [1] 2 3 4 5 6 ... 8   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal