A580 porting - minor progress

  • 125 Replies
Re: A580 porting - minor progress
« Reply #40 on: 05 / February / 2009, 18:15:33 »

You said:

Huh ? You don't need to copy them. Just don't build them in the first place. You only need to generate the .h files if you are adding entry points to sig_ref_*.txt. This is only true if you are adding new features.

the only way to compile now my version is to remove from the command line the "2" in "1 2" so as gensigs doesn't process the second firmware (the 1100one) the created signatures_dryos.h is different than the one in SVN.

What I want to do is just copy signatures_dryos.h from SVN and prevent the compilation from deleting and recreating this file. This was my question: how do I do that?

I've already verified each nstub in stubs_entry.s and corrected some values, i'll write all these in stubs_entry_2.s but with NHSTUB, just to be sure the values i checked will be used.

I think i'll have to use the hex value for a nullsub for the functions keyb_power_on and keyb_power_off, I don't think this firmware has them. Same for strncpy and strrchr. Hope they're not used much.

The bitmap buffer addresses (the ones in hook_raw_image_addr and vid_get_bitmap_fb and I think also vid_get_viewport_fb) are identical in both firmwares so maybe I'll get lucky.

Tommorow I'll review the boot.c and make changes if needed and hopefully I'll see something on the screen. Will keep you updated.


Offline reyalp

  • ******
  • 10016
Re: A580 porting - minor progress
« Reply #41 on: 05 / February / 2009, 18:34:51 »
I don't understand what your problem is. Don't build the .h files, either by removing the sig_ref.bin files, or by making a local modification to the makefile. Or figure out what the problem is with sh in your environment and fix it...

I've already verified each nstub in stubs_entry.s and corrected some values, i'll write all these in stubs_entry_2.s but with NHSTUB, just to be sure the values i checked will be used.
Don't forget what the H stands for.

Re: A580 porting - minor progress
« Reply #42 on: 08 / February / 2009, 21:43:26 »
I've spend a few hours on finding functions and I've finished searching for all the functions in a720's stubs_entry_2.s

So far I haven't been able to find the following functions in a580's firmware:

kbd_pwr_on_short \ these two are actually nullsubs
kbd_pwr_off_0      /

I guess it's normal to not find some functions, as the dryos versions are different, but I'm worried that the camera will not even boot if I don't find these, especially the last two.

How important are these functions, are they used often, are they used during the boot process?

It's going to take me probably a week to correct the code in boot.c, contrary to what I said before - I really don't have a lot of spare time these days to work only on this port.
« Last Edit: 08 / February / 2009, 21:46:17 by mariush »


Offline reyalp

  • ******
  • 10016
Re: A580 porting - minor progress
« Reply #43 on: 08 / February / 2009, 23:21:19 »
PT_Playsound should be findable by the string PT_Playsound.
string referenced by a table of
 char * funcname

ANSI string functions should be findable by looking near where other such functions are found.

PostLEDMessage may not exist, not all cameras do LED control in the same way.

Probably none of these things are critical to booting, you can always grep the source tree and see where they are used.

I don't see kbd_pwr_on_short or kbd_pwr_off_0 in a720 (or the rest of CHDK for that matter... the string kbd_pwr_on_short appears in sx100 boot.c, but only in a comment.)
Don't forget what the H stands for.

Re: A580 porting - minor progress
« Reply #44 on: 09 / February / 2009, 08:19:34 »
In a720, the keyboard functions are above <<DCB "PhySwGpio.c",0>> and the function Task_AudioTsk, in this order (that's how IDA labeled them automatically, using the scripts mentioned in the wiki page):

FFC37068 kbd_pwr_on
FFC370C0 kbd_pwr_off
FFC370E8 kbd_pwr_on_short
FFC370FC kbd_pwr_off_0

In a580 it's

FFC318FC kbd_pwr_on

FFC31968 nullsub_216
FFC3196C nullsub_18

In a720 the kbd_pwr_off is
Code: [Select]
ROM:FFC370C0 kbd_pwr_off                             ; CODE XREF: kbd_read_keys+34p
ROM:FFC370C0                 LDR     R0, =0xC0220000
ROM:FFC370C4                 LDR     R1, [R0,#0xE0]
ROM:FFC370C8                 BIC     R1, R1, #2
ROM:FFC370CC                 STR     R1, [R0,#0xE0]
ROM:FFC370D0                 BX      LR
ROM:FFC370D0 ; End of function kbd_pwr_off

In a580, where it's supposed to be, it's this:

Code: [Select]
ROM:FFC3194C sub_FFC3194C                            ; CODE XREF: kbd_read_keys+34p
ROM:FFC3194C                 MOV     R0, #0
ROM:FFC31950                 B       sub_FFC3134C
ROM:FFC31950 ; End of function sub_FFC3194C

ROM:FFC3134C sub_FFC3134C                            ; CODE XREF: sub_FFC318FC+8p
ROM:FFC3134C                                         ; sub_FFC3194C+4j
ROM:FFC3134C arg_4           =  4
ROM:FFC3134C                 STR     LR, [SP,#unk_FFFFFFFC]!
ROM:FFC31350                 LDR     LR, =0xC0220000
ROM:FFC31354                 LDR     R12, =unk_FFE5C62C
ROM:FFC31358                 MOV     R1, #0
ROM:FFC3135C loc_FFC3135C                            ; CODE XREF: sub_FFC3134C+30j
ROM:FFC3135C                 ADD     R2, R1, R1,LSL#1
ROM:FFC31360                 ADD     R3, R12, R2,LSL#2
ROM:FFC31364                 LDRB    R3, [R3,#8]
ROM:FFC31368                 CMP     R3, #1
ROM:FFC3136C                 LDREQB  R2, [R12,R2,LSL#2]
ROM:FFC31370                 STREQ   R0, [LR,R2,LSL#2]
ROM:FFC31374                 ADD     R1, R1, #1
ROM:FFC31378                 CMP     R1, #0x1C
ROM:FFC3137C                 BLT     loc_FFC3135C
ROM:FFC31380                 LDR     PC, [SP],#arg_4
ROM:FFC31380 ; End of function sub_FFC3134C

Doesn't look like a match to me.

Regarding PT_Playsound there is DCB "PlaySound" but it it's used anywhere. The only other interesting functions I see are two that use "MyCamFunc_PlaySound_MYCAM_COVER_OPEN" and one that contains "PLAYSOUNDDATA" which I assume plays a sound buffer or something

I did search for postledmessage in all the sourcecode but I only found it in a header file, i just asked to be sure.

ok... just one more question...

I found a sub called in taskcreate_LEDCon, that I think it contains the LED addresses:

in a720

Code: [Select]
sub_FFCC9150                            ; CODE XREF: taskcreate_LEDCon+54p
ROM:FFCC9150                 LDR     R2, =0xC02200CC
ROM:FFCC9154                 MOV     R1, #0
ROM:FFCC9158                 STRB    R1, [R0]
ROM:FFCC915C                 STR     R2, [R0,#4]
ROM:FFCC9160                 SUB     R2, R2, #4
ROM:FFCC9164                 STRB    R1, [R0,#0x40]
ROM:FFCC9168                 STR     R2, [R0,#0x44]
ROM:FFCC916C                 LDR     R2, =0xC02200D0
ROM:FFCC9170                 STRB    R1, [R0,#0x80]
ROM:FFCC9174                 STR     R2, [R0,#0x84]
ROM:FFCC9178                 ADD     R2, R2, #4
ROM:FFCC917C                 STRB    R1, [R0,#0xC0]
ROM:FFCC9180                 STR     R2, [R0,#0xC4]
ROM:FFCC9184                 STRB    R1, [R0,#0x200]
ROM:FFCC9188                 LDR     R1, =0xC02200C4
ROM:FFCC918C                 LDR     R2, =0xC02200C0
ROM:FFCC9190                 STR     R1, [R0,#0x204]
ROM:FFCC9194                 MOV     R1, #1
ROM:FFCC9198                 STRB    R1, [R0,#0x240]
ROM:FFCC919C                 STR     R2, [R0,#0x244]
ROM:FFCC91A0                 STRB    R1, [R0,#0x280]
ROM:FFCC91A4                 STRB    R1, [R0,#0x2C0]
ROM:FFCC91A8                 B       sub_FFD9B940
ROM:FFCC91A8 ; End of function sub_FFCC9150

so :
ROM:FFCC91C8 dword_FFCC91C8  DCD 0xC02200CC          ; DATA XREF: sub_FFCC9150r
ROM:FFCC91CC dword_FFCC91CC  DCD 0xC02200D0          ; DATA XREF: sub_FFCC9150+1Cr
ROM:FFCC91D0 dword_FFCC91D0  DCD 0xC02200C4          ; DATA XREF: sub_FFCC9150+38r
ROM:FFCC91D4 dword_FFCC91D4  DCD 0xC02200C0          ; DATA XREF: sub_FFCC9150+3Cr

in a580

Code: [Select]
ROM:FFCC5A6C sub_FFCC5A6C                            ; CODE XREF: taskcreate_LEDCon+54p
ROM:FFCC5A6C                 LDR     R2, =0xC02200CC
ROM:FFCC5A70                 MOV     R1, #0
ROM:FFCC5A74                 STRB    R1, [R0]
ROM:FFCC5A78                 STR     R2, [R0,#4]
ROM:FFCC5A7C                 SUB     R2, R2, #4
ROM:FFCC5A80                 STRB    R1, [R0,#0x40]
ROM:FFCC5A84                 STR     R2, [R0,#0x44]
ROM:FFCC5A88                 LDR     R2, =0xC02200D0
ROM:FFCC5A8C                 STRB    R1, [R0,#0x80]
ROM:FFCC5A90                 STR     R2, [R0,#0x84]
ROM:FFCC5A94                 STRB    R1, [R0,#0x200]
ROM:FFCC5A98                 SUB     R1, R2, #0xC
ROM:FFCC5A9C                 STR     R1, [R0,#0x204]
ROM:FFCC5AA0                 MOV     R1, #1
ROM:FFCC5AA4                 SUB     R2, R2, #0x10
ROM:FFCC5AA8                 STRB    R1, [R0,#0x240]
ROM:FFCC5AAC                 STR     R2, [R0,#0x244]
ROM:FFCC5AB0                 STRB    R1, [R0,#0x280]
ROM:FFCC5AB4                 STRB    R1, [R0,#0x2C0]
ROM:FFCC5AB8                 B       sub_FFDAF0CC
ROM:FFCC5AB8 ; End of function sub_FFCC5A6C


ROM:FFCC5AD8 dword_FFCC5AD8  DCD 0xC02200CC          ; DATA XREF: sub_FFCC5A6Cr
ROM:FFCC5ADC dword_FFCC5ADC  DCD 0xC02200D0          ; DATA XREF: sub_FFCC5A6C+1Cr

I see in platform/a720 code LED_PR 0xc02200C4 and LED_AF 0xc0220080 so I think I'm on the right tracks here, this is where I can determine the led addresses from.
Could you determine them just from the code above?


Offline reyalp

  • ******
  • 10016
Re: A580 porting - minor progress
« Reply #45 on: 10 / February / 2009, 01:28:32 »
if the what you think should be kbd_pwr_off is called in code equivalent to where the 720 one is (which it appears to be by the offset at least) it's probably right.

Regarding PT_Playsound there is DCB "PlaySound" but it it's used anywhere.
I bet it is, just not somewhere IDA has turned into an address for you. Search for the address of the string as a sequence of bytes, keeping in mind that it's little endian.
at FFE63E0C

Looks like you are on the right track for LED addresses. Given some of the values are the same, it's probably a fair bet it uses exactly the same setup as the 720. If it were me, I'd just try em. (this isn't entirely risk free since you are writing to MMIO addresses, but that's what I'd do ;) ... realistically, you know those are associated with LEDs at least, so chances are the worst that would happen is lighting up the wrong one)
« Last Edit: 10 / February / 2009, 02:56:58 by reyalp »
Don't forget what the H stands for.

Re: A580 porting - minor progress
« Reply #46 on: 14 / February / 2009, 19:10:45 »
Some good news, I think :)

I've corrected the whole boot.c and I'm going to do movie_rec and capt_seq in the next days...

I just left the standard calls to the subs in the firmware until I'll be able to do that and I compiled the firmware..

I've ran into some problems initially:

Code: [Select]
../platform/a580/libplatform.a(wrappers.o): In function `lens_set_zoom_speed':
wrappers.c:(.text+0x1e8): undefined reference to `_SetZoomActuatorSpeedPercent'
../platform/a580/libplatform.a(wrappers.o): In function `play_sound':
wrappers.c:(.text+0x290): undefined reference to `_PT_PlaySound'
../platform/a580/libplatform.a(wrappers.o): In function `MakeAFScan':
wrappers.c:(.text+0xccc): undefined reference to `_MakeAFScan'
../platform/a580/libplatform.a(wrappers.o): In function `ubasic_set_led':
wrappers.c:(.text+0xfa4): undefined reference to `_PostLEDMessage'

... but I added NHSTUB to these pointing to nullsub, compiled again and it compiled successfully.

I copied to camera, and after about two seconds after I press the power button the blue print led blinks, the screen says no image and card loaded and the camera freezes.

I'm not sure what makes the blue led blink cause I removed all the blinking led from boot.c, I just left there

#define DEBUG_LED 0xC02200D0    

which is one of the two values I found before.

Besides this there's only the panic function in the loader folder which has:

#define LED_PR 0xC02200C4

Right now, if you could help me out with information about what this does, it would be great:

Code: [Select]
void CreateTask_spytask() { //#fs
        _CreateTask("SpyTask", 0x19, 0x2000, core_spytask, 0);

}; //#fe

void CreateTask_PhySw() { //#fs
        _CreateTask("PhySw", 0x18, 0x800, mykbd_task, 0);
}; //#fe

Basically, I'd like some info about those parameters, where are they taken from and so on....

Also, there's two value that I don't understand how they're computed or where are they are taken from:

Code: [Select]
void *vid_get_viewport_fb_d()
    return (void*)(*(int*)0x540C);  //5410

Code: [Select]
void *vid_get_viewport_live_fb()
//    return (void*)0;//0x10670ee0;
    void **fb=(void **)0x21D0; // defined in 0xFFCA0EF4 in a580 and FFC298C4 in a720 ?
    unsigned char buff = *((unsigned char*)0x2084); // 0x6928 ?!
    if (buff == 0) {
        buff = 2;
    else {
    return fb[buff];


Offline reyalp

  • ******
  • 10016
Re: A580 porting - minor progress
« Reply #47 on: 14 / February / 2009, 19:42:19 »
Based on similarity to vxworks vxworks, the parameters to CreatTask are name, priority, stack size, entry point, and I'm not sure what the zero is. If you look at the firmware code that spawns all the tasks (which is copied in modified form to boot.c, you should have plenty of examples. The PhySw task replaces the canon firmware PhySw, and the stack gets replaced later (which is something we should do differently, but that's another story). Spytask is the task that runs the main chdk stuff and is completely new.

In general, looking over several cams should give you an idea of whether the values are camera specific.

the fb_d and live_fb are tricky, but neither one should be essential to booting the cam (they are used for histogram, md etc.) Basically, you'll need to either find the code based on similarity to other cams, or inspect memory to find the correct variable. The used variables are typically referenced by an offset, so just searching for the final value won't find you anything. Some cameras code actually have (constant1 + constant2) as the variable address, or have the base address in a comment. In that case, you can search the known cameras code for references to the base address and offset, and then use that to find the corresponding code and base address in the came you are looking for.
Don't forget what the H stands for.

Re: A580 porting - minor progress
« Reply #48 on: 15 / February / 2009, 19:40:28 »
I see that Dabian on CHDK Wiki has managed to install GCC on his computer so it doesn't really make sense to keep what I've done so far all to myself.

Here's the files I worked on so far ( note: this applies to A580 101b only as far as I know, I haven't tested (and I can't test on) others)

It's loaded by the camera but somewhere in the boot process I think it panics and freezes the camera. The camera just says "no images" (because there are no pics on the 32MB card I use) and that card is locked and freezes.

Please don't assume the stubs_*.s are all correct, it would be great if people trying to port this camera can verify them for me.

I've added a debugblink() function in boot.c which can be used to test if the code is processed until a certain point.

I'm using cmake.bat to compile it, basically it runs a clean and then builds diskboot.bin

I'm now working on the movie_rec.c file and adapting it so I don't really care that there may be  some bugs in the boot.c yet.

PS. The blue print LED has the same address as A720, 0xC02200C4 and blinking it is the same as in A720. Haven't tried other addresses - it's not because I'm lazy, it's simply because I don't like to open the battery door (and weaken it in the process), pull out cards, copy stuff and put it back in the camera a million times.

Ps2: I've written a lot of comments to keep track of how I determined stuff in the files. I'm using Ultraedit with tab width 2 to work on the files so if the comments seem to be in weird locations or out of the usual screen size, it's because of that.
« Last Edit: 15 / February / 2009, 20:02:59 by mariush »


Offline reyalp

  • ******
  • 10016
Re: A580 porting - minor progress
« Reply #49 on: 15 / February / 2009, 19:45:55 »
Just a FWIW, you shouldn't really need the capt_seq and movie stuff to get up and running. These are needed for raw and various overrides, but it may be more effective to not even try to replace these tasks until you've got the rest booting. You could just run the factory versions of these tasks for now.

Once you have the UI displaying and the ability to boot and write to files, debugging the rest will be significantly simpler.
Don't forget what the H stands for.


Related Topics