A580 porting - minor progress - page 7 - General Discussion and Assistance - CHDK Forum supplierdeeply

A580 porting - minor progress

  • 125 Replies
Re: A580 porting - minor progress
« Reply #60 on: 18 / February / 2009, 08:39:48 »
Here's the movie_rec.c file, all prepared and working (well it compiles properly when it's called from boot.c):


It took me a few hours to debug it because I forgot an "=" sign in front of an offset in a "LDR R1.." line...

I still don't have a clue why the port crashes after entering the last sub in boot.c, where the new FAT32 detection code is... though i'm not sure if that code is responsible or not because it crashes even with that disabled.
I'll keep investigating...

Re: A580 porting - minor progress
« Reply #61 on: 18 / February / 2009, 13:29:07 »
Ok... I have a few questions..

As I said in my previous posts, the compiled diskboot causes a panic inside the last sub in boot.c, the one that contains "DataGhost's FAT32 autodetection code" and freezes the camera.

I have tried disabling that code completely and it still froze the camera.

Today, I've decided to remove the call to this modified sub and leave the original in place and I've found that in this case, everything goes fine and the whole branch of modified functions returns in a sub involved way up in the boot process, the one with string "uAC_Boot" : sub_FFC5E72C_my

The whole SDHC thing is shown here:

Code: [Select]

//  Startup -> FFC1A4C0 -> sub_FFC1A090 ->                          -> sub_FFC5ED64 (@FFC1A444) -> sub_FFC5E72C (uAC_Boot)(@FFC5EE08) -> FFC5FEF0 (taskCreate_InitFileModules) (@FFC5E778)
//                              \-> sub_FFC5FBC4 (@FFC1A37C) -> sub_FFC5FB60 ->/
//                   ->                         StartFactoryModeController =>||
//  taskCreate_InitFileModules -> FFC5FEA0 task_InitFileModules -> sub_FFC58A54 -> sub_FFC3D588 -> sub_FFC3D3C4 -> sub_FFC3D154

Here's this sub where it happens:

Code: [Select]
                "STMFD   SP!, {R4-R8,LR}\n"
                "LDR     R7, =0x8002\n"
                "LDR     R4, =0x5738\n"
                "CMP     R0, #2\n"
                "MOV     R6, R1\n"
                "MOV     R5, #1\n"
                "BEQ     loc_FFC5E7B8\n"
                "BGT     loc_FFC5E7A0\n"
                "CMP     R0, #0\n"
                "BEQ     loc_FFC5E7E4\n"
                "CMP     R0, #1\n"
                "BNE     loc_FFC5E87C\n"
                "MOV     R0, #8\n"
                "BL      sub_FFC5DCB4\n" // uCameraConState
                "BL      sub_FFC5FF2C\n" // taskcreate_CommonDrivers
                "BL      sub_FFC609F8\n" // uDispSwLock
                "LDR     R1, =0xFFC5E9DC\n" // aAcBootpb   ; "AC:BootPB"
                "MOV     R0, #0x20\n"
                "BL      sub_FFC5556C\n" // qCameraLog
                "BL      sub_FFC5FEF0_my\n" // Continue to taskcreate_InitFileModules

                "BL      sub_FFC5FFFC\n"
                "BL      sub_FFC1A5B0\n"
                "LDR     R0, =0x4004\n"
                "BL      sub_FFC19BAC\n"
                "LDR     R0, [R4,#0x68]\n"
                "CMP     R0, #0\n"
                "BNE     loc_FFC5E85C\n"
                "BL      sub_FFC19D90\n" // taskcreate_StartupImage
                "B       loc_FFC5E860\n"
                "CMP     R0, #6\n"
                "STREQ   R5, [R4,#0x28]\n"
                "BEQ     loc_FFC5E870\n"
                "SUB     R12, R0, #0x2000\n"
                "SUBS    R12, R12, #4\n"
                "BNE     loc_FFC5E87C\n"
                "SUB     R12, R6, #0x1100\n"
                "SUBS    R12, R12, #0x62\n"
                "BNE     loc_FFC5E7D4\n"
                "MOV     R1, R7\n"
                "MOV     R0, #0\n"
                "BL      sub_FFC614F4\n"
                "STR     R5, [R4,#0x60]\n"
                "BL      sub_FFC60B90\n"
                "BL      sub_FFC60E28\n"
                "BL      sub_FFC5E2D8\n"
                "B       loc_FFC5E874\n"
                "MOV     R0, #7\n"
                "BL      sub_FFC5DCB4\n" // uCameraConState
                "MOV     R0, R7\n"
                "BL      sub_FFC19BAC\n"
                "BL      sub_FFC5FF2C\n" // taskcreate_CommonDrivers
                "BL      sub_FFC609F8\n" // uDispSwLock
                "LDR     R1, =0xFFC5E9EC\n" // aAcBootrec  ; "AC:BootRec"
                "MOV     R0, #0x20\n"
                "STR     R6, [R4,#0x18]\n"
                "BL      sub_FFC5556C\n" // qCameraLog
                "LDR     R1, =0xFFC5E9F8\n" // aAcInitlens ; "AC:InitLens"
                "MOV     R0, #0x20\n"
                "BL      sub_FFC5556C\n" // qCameraLog
                "STR     R5, [R4,#0x28]\n"
                "BL      sub_FFC19D20\n"
                "BL      sub_FFC19C74\n"
                "LDR     R0, [R4,#0x1C]\n"
                "LDR     R1, [R4,#0x20]\n"
                "ORRS    R0, R0, R1\n"
                "BLNE    sub_FFC5F1CC\n"
                "LDR     R0, [R4,#0x68]\n"
                "CMP     R0, #0\n"
                "BNE     loc_FFC5E848\n"
                "BL      sub_FFC19D90\n" // taskcreate_StartupImage
                "B       loc_FFC5E850\n"
                "BL      sub_FFC14A98\n"
                "BL      sub_FFC1A5E8\n"
                "BL      sub_FFC5FEF0_my\n" // Continue to taskcreate_InitFileModules
                "BL      sub_FFC5FF68\n"
                "B       loc_FFC5E874\n"
                "BL      sub_FFC14A98\n"
                "BL      sub_FFC5FF98\n"
                "LDR     R0, [R4,#0x30]\n"
                "CMP     R0, #0\n"
                "BEQ     loc_FFC5E874\n"
                "BL      sub_FFC5F214\n"
                "MOV     R0, #0\n"
                "LDMFD   SP!, {R4-R8,PC}\n"
                "MOV     R0, #1\n"
                "LDMFD   SP!, {R4-R8,PC}\n"
}; //#fe

My guess is that everything goes OK at least until task_StartupImage as the Canon splash screen shows and then it goes right away to "Card Locked", "no images" and the blue led blinks once.

If I remember correctly, somewhere the code is supposed to do something in regard to diskboot.bin, so that when rebooted the camera ignores it and the card lock... does this happen in the last sub when the FAT32 code?

what puzzles me also is that there are very minimal differences between a720 and a580... in just a couple of subs there was some code missing or a nullsub in a580 and a regular sub in a720 but in these disk related subs they're identical so I can't figure why it doesn't work.
« Last Edit: 18 / February / 2009, 13:43:06 by mariush »


Offline ewavr

  • ****
  • 1057
  • A710IS
Re: A580 porting - minor progress
« Reply #62 on: 18 / February / 2009, 13:48:29 »
somewhere the code is supposed to do something in regard to diskboot.bin, so that when rebooted the camera ignores it
In task_Startup_my() (search in boot.c for "// StartDiskboot" comment)
and the card lock...
In keyboad task (in kbd.c search for "SD_READONLY_FLAG").

Re: A580 porting - minor progress
« Reply #63 on: 18 / February / 2009, 15:09:14 »
Yeah, StartDiskBoot is disabled there... so it's definitely not that the problem...
Could that Fat32 asm code have issues with the 32MB SD card I use? Maybe I'll try it out on a 2GB card and see if it makes a difference...

Re: A580 porting - minor progress
« Reply #64 on: 18 / February / 2009, 17:42:55 »
Apparently the code in the last sub didn't work because I left "BLX R12" uncommented or something like that. I left it like that just to see if asm gives me errors but it didn't so I assumed it worked.
Now I commented it out and replaced it with the two asm lines that do the same thing and the camera no longer crashes in that last sub... but it also doesn't crash at that sub from above that I mentioned in my previous comments, it crashes somewhere else, have to place blink code again in various spots to see where it crashes...

Re: A580 porting - minor progress
« Reply #65 on: 19 / February / 2009, 20:02:00 »
An update on the whole stuff here...

I've determined that the blue short blink that I assumed it's a panic call or something is actually this sequence of code from core_spytask in main.c:

Code: [Select]

I've disabled the mykbd_task and set msleep(500) and the led stayed on for a longer time so I'm sure it goes up to here.

Below that it's the following code:

Code: [Select]

I've added a "started / msleep /  finished" sequence at the start of gui_init and a debugblink (my function that keeps blinking the led forever) after the gui_init call because I assumed the gui_init function fails because of some bad memory address in lib.c.

However, it doesn't even reach the gui_init so it probably freezes in conf_restore() ?

I guess the next step is reviewing that conf_restore function and as I assume it uses some file reading/directory functions  (i haven't inspected it yet) I probably have to review the file related functions in stub_entry_2.s

If I'm saying something stupid please contradict me...

Re: A580 porting - minor progress
« Reply #66 on: 20 / February / 2009, 18:58:20 »
After several compiles and tests I've determined that it stops working when conf_load_defaults is called:

Code: [Select]
void conf_load_defaults() {
    register int i;

    for (i=0; i<CONF_NUM; ++i) {
        switch (conf_info[i].type) {
            case CONF_DEF_VALUE:
                memcpy(conf_info[i].var, &(conf_info[i].i), conf_info[i].size);
            case CONF_DEF_PTR:
                memcpy(conf_info[i].var, conf_info[i].ptr, conf_info[i].size);
        if (conf_info[i].func) {

I don't think I have enough experience with C because I don't understand how this function works or what it tried to do?
I assume it sets some default values by copying some data (because it uses memcpy) but the whole conf_info stuff seems to complex to understand it.

If I comment this out, the camera starts fine and doesn't freeze, I can access the standard camera menu just fine pressing the MENU button but when I switch it to record mode I think it shuts down.

Well, even if I start it directly in record mode it opens the lens, shows a static image of what's in front of the camera for a few ms and then shuts down without closing the lens. I have to remove the card and power the camera to have it retract the lens.

I need some info about that conf issue first and potential causes for it not working, if it's really important for everything to work.
Also, would it help if I'd have a CCHDK.cfg file to place on the card? If yes, can anyone send a cfg file to me (does it matter if I compile using svn version 672) ?

I'll make another pack with the files I worked on soon (I had some incorrect values in lib.c for example), I now have to keep this short as I have other work to do.
« Last Edit: 20 / February / 2009, 19:01:03 by mariush »


Offline reyalp

  • ******
  • 14082
Re: A580 porting - minor progress
« Reply #67 on: 20 / February / 2009, 19:16:12 »
Could you have the wrong entry point for memcpy ?

Alternately, it could be one of the func() calls crashing. Maybe commenting that out would narrow it down. Another would be to find which index it crashes on.
Don't forget what the H stands for.

Re: A580 porting - minor progress
« Reply #68 on: 20 / February / 2009, 21:01:38 »
Without really looking, I would guess that its a null or void pointer of some kind, or maybe a segmentation violation (or equivalent failure in ARM).  I hope I'll get time to look closer at it.

The memcopy takes a slice of memory and makes a copy in another slice.  For that to work, it has to know where the memory starts, it has to have access to that memory and it has to have access to the destination, and the destination has to be defined as well.

I guess its interesting to know if conf_info is defined, and if it is, if conf_info.type is defined.

OK .. guess you thought of all this yourself .. I should go to bed. :)

Re: A580 porting - minor progress
« Reply #69 on: 20 / February / 2009, 21:42:58 »
I'll add some blinking code in that for and I'll count how many times it blinks, therefore I'll probably know where it crashes, give or take a few lines... I just don't have time right now.

I know what memcpy does as I've used the Windows API equivalent in VB6 for string operations (VB6 works internally in unicode and is slow). I'm 99.99 % sure memcpy is determined correctly as it's exactly identical to A720's memcpy.

I was looking more to an explanation regarding what's the reason for that conf array and why it needs to copy memory from one place to another. Sounds like a lot of memory fragmenting and small memory allocations right from the start and maybe it could be avoided.


Related Topics