DryOS - some success - page 4 - DryOS Development - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 [4] 5 6 7 8 9 ... 23   Go Down

DryOS - some success

  • 220 Replies
  • 184604 Views
*

Offline geekmug

  • *
  • 10
Re: DryOS - some success
« Reply #30 on: 04 / January / 2008, 21:33:31 »
Advertisements
I have started to try to reproduce your success on my S5IS. Some immediate problems I ran into were that I hadn't located some of the functions you have.. perhaps you can provide some guidance as to how you did so. In contrast, I think I located maybe a couple functions that you didn't.

You can find CreateTaskStrict by looking for the usage the string "StrictWrapper.c" with an Assert in combination with a call to a CreateTask.. not sure that drop in the bucket matters much. IsStrobeChargeCompleted can be found by looking at its SSAPI counterpart which can be found by looking for the use of "SSAPI::IsStrobeChargeCompleted". I've also mapped out the open/read/write/close/lseek functions via the Fx_Fut functions..

Nevertheless, the biggest problem I have at the moment is locating some of the setup code that you did and some of the hardware addresses (like in entry.S, the control for the SD Card power).. I'm not sure how you figured these things out other than blind guessing.. :blink:

I could list off what stubs I NSTUB values I am missing, but the list is not short. Basically, everything you put in "used during init" is unknown to me except for "CreateTaskStartup" (which I am hoping is the same as what I named "SetupTask_Startup", I have a whole list of SetupTask_x entry points). Nevertheless, any wisdom you can provide to finding those or for finding everything having to do with the keyboard, as I have had zero success there either.

Finally, I am working entirely within Linux, and I find the trunk code to have a circular dependency related to the "tools" subdir, and can't be bothered to figure out why. So, I have been working against GrAnd's branch.. I hope that doesn't 'cause any major headaches..

-Scott
Logged
*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: DryOS - some success
« Reply #31 on: 05 / January / 2008, 03:56:11 »
Quote from: jeff666 on 03 / January / 2008, 07:19:57
Edit: It turns out that 3 buttons, SHOOT_HALF, SHOOT_FULL and ERASE are in physw_status[1]. Since the upper two bytes from [2] weren't used, I copied the relevant bits there. But this should be changed to something more generic later.

Sorry for maybe late comment... You can see at the sources (kbd.c, keymap) of S- or G-series. It also uses more than one variable for buttons.
Logged
CHDK Developer.
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: DryOS - some success
« Reply #32 on: 05 / January / 2008, 06:03:35 »
Quote
I have started to try to reproduce your success on my S5IS.

Nice to see you back. For those who don't know, geekmug did the first S5 firmware dump.

Quote
Some immediate problems I ran into were that I hadn't located some of the functions you have..
perhaps you can provide some guidance as to how you did so. In contrast, I think I located maybe a couple functions that you didn't.

To find out the rough location of a function use the DRYOS-IDA-function-list.txt file in my zip and look at the a720-firmware. I did the same using the stubs_entry.S from the a710 to find some of the functions in dryos.

In general I find it a good idea to put the IDA-function-list into the archives we post. It helps the other developers to reproduce and/or check our success. You get the list from the context-menu in the IDA functions-window. Just copy-n-paste into a text file. Also write the time of creation into the file, as this information is subject to change.

Quote
You can find CreateTaskStrict by looking for the usage the string "StrictWrapper.c"

I'm not sure if we really need this function, but it a useful information, nonetheless. The A720-firmware doesn't mention "StrictWrapper.c" anywhere. Instead it refers to "KernelMisc.c". The functions remain the same, though. It seems like canon renamed one of their source files.

Quote
IsStrobeChargeCompleted can be found by looking at its SSAPI counterpart which can be found by looking for the use of "SSAPI::IsStrobeChargeCompleted". I've also mapped out the open/read/write/close/lseek functions via the Fx_Fut functions..

Everything that's mentioned somewhere with its name is fairly easy to find. Fun are the file-operations. They appear several times, work differently and are all used independent of the functions that follow the other naming convention.

Quote
Nevertheless, the biggest problem I have at the moment is locating some of the setup code that you did and some of the hardware addresses (like in entry.S, the control for the SD Card power).. I'm not sure how you figured these things out other than blind guessing.. :blink:

Well, I sent my camera to Chuck Norris and asked him to interrogate it. Two days later it returned and promised to be much more cooperative as long as I don't send it to Chuck, again :D

Actually such things can be found out by using text search. Have IDA search the disassembly of a known camera for "=0xC02200". One of the hits should look somewhat like
Code: [Select]
LDR R2, 0xC0220000
MOV R3, #0x44
STR R3, [R2, #0x48]

If the address you are looking for is actually 0xC0220048, you found the location in the explored firmware. Look at the corresponding location in your own firmware and you should see the address for your camera.

Quote
Basically, everything you put in "used during init"

Forget this! That was an idea I had when I started, but it turns out that it's nonsense. These are addresses used in uHwSetup. It is one of the duplicated functions in boot.c. These names are used only in boot.c and the code itself is just a duplicate from the original firmware. So just stick to sub_XXXXXXXX and write descriptive names in the comment.

Quote
I have a whole list of SetupTask_x entry points

I think "SetupTask_x" is misleading. The code you found are the tasks itself. Only a fraction of them has anything to do with a setup-process. I suggest you stick to "task_x". Btw, I'm not 100% consistent, either. My "task_Startup" is just named "Startup".

Quote
Nevertheless, any wisdom you can provide to finding those or for finding everything having to do with the keyboard, as I have had zero success there either.

For the keyboard you will only need one name: "PhySw".
Actually there is a "task_PhySw" which is spawn directly from "task_Startup".

Code: [Select]
ROM:FF823668 task_PhySw                             
ROM:FF823668                 STMFD   SP!, {R4,LR}
ROM:FF82366C                 LDR     R4, =0x1CD0  <-- ---------- this is physw_run
ROM:FF823670                 B       loc_FF823688
ROM:FF823674 loc_FF823674                           
ROM:FF823674                 MOV     R0, #0xA
ROM:FF823678                 BL      sub_FF82AC20 ; SleepTask(10)
ROM:FF82367C                 BL      sub_FF823A6C      <-------- This is kbd_p1_f
ROM:FF823680                 CMP     R0, #1
ROM:FF823684                 BLEQ    sub_FF82330C   <--------- This is kbd_p2_f
...
ROM:FF823A6C kbd_p1_f                                ; CODE XREF: task_PhySw
ROM:FF823A6C                 STMFD   SP!, {R1-R5,LR}
ROM:FF823A70                 MOV     R4, #0
ROM:FF823A74                 BL      sub_FF823990 <- this is kbd_read_keys
ROM:FF823A78                 LDR     R1, =0x11AB0  <-- kbd_p1_f_cont entrypoint here

I hope this will get you an Idea. Just ckeck the entrypoints in my stubs_entry_2.S, find them in the a720-firmware and locate the same code in your own. Btw, since I had the S5-firmware opened: your physw_status is 0x11ABC.
It seems like the S5 doesn't have kbd_power_on and kbd_power_off. You might want to have a look how the kbd is handled with the S3.

Quote
So, I have been working against GrAnd's branch..

Hell! That causes some major headaches :)

No, actually it's useful if we get a branch that's current. You may just have to figure out some things on your own as you are the first one to do it.

Cheers.
Logged
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: DryOS - some success
« Reply #33 on: 05 / January / 2008, 06:50:30 »
As mentioned last night, I'm trying to establish a way of hooking particular tasks as used with VxWorks. Since it didn't work right away (and still doesn't) I quickly hacked something to view the task-table.

I thought you folks may find this picture funny/interesting: http://img181.imageshack.us/my.php?image=capture00016rq3.jpg

First column is a counter, followed by the address of the task and its name. Note the addresses of the tasks that were introduced or diverted by CHDK.

Edit:
Well, bad news. It appears that the hook gets called when a task is spawn and I can change the tasks address but the changes aren't reflected in any way. This makes the hook purely informative as it doesn't allow any changes. I'll check again, if I missed something but will drop the subject if I don't find something in a short time.

Cheers.
« Last Edit: 05 / January / 2008, 08:09:05 by jeff666 »
Logged
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: DryOS - some success
« Reply #34 on: 05 / January / 2008, 10:31:51 »
Grr, I'm not getting very far with my S5... In the function where wHwSetup_my is hooked
Code: [Select]
"LDR     R1, =uHwSetup_my\n"         // followup to own functiona call to sub_FF812D84 is made, which calls ... which calls .. and so on, until I reach sub_FF818BB0 (A720 equiv sub_FFC08C98, identical in both cameras). For some reason execution stops at
Code: [Select]
"STRNE   R1, [R2,#4]\n"and I don't know why. The addresses it's referencing look quite alike in both firmwares but for some reason it's acting up in the S5. If anyone has any ideas, please :) In the meantime, I guess I'll look over the complete code again to make sure I didn't make an error anywhere.
Logged
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: DryOS - some success
« Reply #35 on: 05 / January / 2008, 11:09:57 »
Quote
explanation ...sort of

Well, I have no idea what you are talking about ;)

The functions in boot.c should exist in your firmware, too. They are probably slightly different but identical enough to trace them manually in IDA. So open boot.c in your editor and look for your equivalent of sub_FFC001a4. Now follow the functions I copied into boot.c and follow the same line of execution in IDA. If you reached task_Startup (which looks a little different in the S5 1.0a) you've discovered most of what's necessary to boot the camera.

Now change boot.c by *not* jumping into the first copied function (sub_FFC01A4_my) but to its original place in the firmware. You should get a boot loop. You get it confirmed by blinking an LED - just turning on only confirms the first execution of the code, so turn on - wait - turn off - wait again then go on. Always make small changes, then test.

One thing I forgot to mention is that you will need to change platform/<dev>/sub/<rev>/makefile.inc

You need to change
* MEMISOSTART, CHDK gets relocated there
and
* ROMBASEADDR

MEMISOSTART employs a gap that is created "XXX HERE XXX" (see below)
Code: [Select]
void __attribute__((naked,noinline)) sub_FFC00FB8_my() { //#fs
        asm volatile (
              //"STR     LR, [SP,#0xFFFFFFFC]!\n"
              "STR     LR, [SP,#-4]!\n"
              "SUB     SP, SP, #0x74\n"
              "MOV     R0, SP\n"
              "MOV     R1, #0x74\n"
              "BL      sub_FFE3B620\n"
              "MOV     R0, #0x53000\n"
              "STR     R0, [SP,#0x74-0x70]\n"
              "LDR     R0, =0xCD024\n"          // 0x9d024 + 0x30000  XXX HERE XXX
              "LDR     R2, =0x2ABC00\n"
              "LDR     R1, =0x2A4968\n"
              "STR     R0, [SP,#0x74-0x6C]\n"
              "SUB     R0, R1, R0\n"


What happens is:
  • the firmware copies an amount of memory from ROM to RAM. This happens at FFC00130 (A720). Check the declarations at the beginning of boot() and you will recognize the numbers.
  • The firmware code that copies this memory is skipped and instead copied in boot().
  • The main memory pool (originally) starts right above this limit. Its address is indicated by R0 in the shown code.
  • We move the memory pool a little up by adding 196k (0x30000), thus creating room for CHDK to live. This room is referred to in MEMISOSTART

Originally only 128k were added, but as reported in this thread my code was overwritten. Thus everything is moved up a little more.

So before anything can work, you have to adjust these numbers.

Cheers.
Logged
*

Offline mx3

  • ****
  • 372
Re: DryOS - some success
« Reply #36 on: 05 / January / 2008, 12:07:30 »
Quote from: jeff666 on 05 / January / 2008, 06:50:30
Well, bad news. It appears that the hook gets called when a task is spawn and I can change the tasks address but the changes aren't reflected in any way. This makes the hook purely informative as it doesn't allow any changes. I'll check again, if I missed something but will drop the subject if I don't find something in a short time.

but you can kill / suspend task.
can you?
Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline DataGhost

  • ****
  • 314
  • EOS 40D, S5IS
    • DataGhost.com
Re: DryOS - some success
« Reply #37 on: 05 / January / 2008, 12:25:57 »
Quote
The functions in boot.c should exist in your firmware, too. They are probably slightly different but identical enough to trace them manually in IDA. So open boot.c in your editor and look for your equivalent of sub_FFC001a4. Now follow the functions I copied into boot.c and follow the same line of execution in IDA. If you reached task_Startup (which looks a little different in the S5 1.0a) you've discovered most of what's necessary to boot the camera.

Now change boot.c by *not* jumping into the first copied function (sub_FFC01A4_my) but to its original place in the firmware. You should get a boot loop. You get it confirmed by blinking an LED - just turning on only confirms the first execution of the code, so turn on - wait - turn off - wait again then go on. Always make small changes, then test.
I'm manually jumping to the restartcode in the firmware itself, offset by a bit (so it matches the first opcode in the resetcode). Works like a charm and I get lots of reboot loops when I want them. That's also how I determined that some functions didn't return or that the camera just stopped working at some opcode.

Quote
One thing I forgot to mention is that you will need to change platform/<dev>/sub/<rev>/makefile.inc

You need to change
* MEMISOSTART, CHDK gets relocated there
and
* ROMBASEADDR

MEMISOSTART employs a gap that is created "XXX HERE XXX" (see below)
[..]
Yep, I did that, fixed it for the proper values in my firmware, or so I think.

Quote
What happens is:
  • the firmware copies an amount of memory from ROM to RAM. This happens at FFC00130 (A720). Check the declarations at the beginning of boot() and you will recognize the numbers.
  • The firmware code that copies this memory is skipped and instead copied in boot().
  • The main memory pool (originally) starts right above this limit. Its address is indicated by R0 in the shown code.
  • We move the memory pool a little up by adding 196k (0x30000), thus creating room for CHDK to live. This room is referred to in MEMISOSTART
I think I should look into it more carefully, try to understand what *EXACTLY* is happening and why, else I'll probably not get this to work. Anyway, in the meantime I wrote a piece of ASM that can dump r0-r5 through the blinker :p but the values it returned don't really make any sense to me, so I still don't know why it hangs there. I guess I just made some mistakes elsewhere and missed them. I don't think I'll have a lot of time for today, so I don't think I'll get anything nice going soon.
Logged
*

Offline jeff666

  • ****
  • 181
  • A720IS
Re: DryOS - some success
« Reply #38 on: 05 / January / 2008, 13:15:09 »
Quote
but you can kill / suspend task.
can you?

Good question. Didn't find anything implies such features. After all, it's not that bad. We just have to copy more code into boot.c until we can intercept ShootSeqTask. That's the only thing that's missing. We spawn spytask ourself, we replace PhySw in Startup. The remount doesn't seem to be needed anyways.

I just had a look into the (A720) firmware and it turns out that there are "only" three further subs until we can intercept ShootSeqTask.

More news:
File access seems easier that previously thought. File creation needs another flag in addition to O_CREAT and O_WRONLY. Can't name it, yet but it's value is 0x100. I set this additional bit in core/conf.c:conf_save() and trunk now writes and reads its configuration.

The entry-points for Open, Close, Read and Write need to be found as they are called from platform/generic/wrappers.c.


@DataGhost
I just remember that I encountered some strange behaviour that's similar to what you get. It happens in the firmwares own copy_data-code. It fails when executed from boot.c. I didn't find out why and was satisfied when the CHDK-copy-function worked. You can try to rewrite or skip a section of code.

Another thing I had to think hard about was a "STRD"-command which is called in the firmware. GCC complains about "command not supported on this processor" and I had to find out what it does and rewrote it to two single "STR" commands. I left a comment in the source file, so you should see it.

If you have absolutely no clue what's going wrong, it's never a bad idea to load the binary in IDA and look if the code got changed by gcc.

Cheers.
Logged
*

Offline obsidian

  • *
  • 31
  • A710IS
Re: DryOS - some success
« Reply #39 on: 05 / January / 2008, 14:27:57 »
STRD might be Store Register Dword
like STRB=Store Register Byte,
STRH=Store Register Halfword
Logged
A710IS + 4GB SanDisk Ultra II
Pages: 1 2 3 [4] 5 6 7 8 9 ... 23   Go Up
« previous next »
 

Related Topics