Resuming activity from the LED blinker program - page 3 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 [3] 4   Go Down

Resuming activity from the LED blinker program

  • 37 Replies
  • 14572 Views
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #20 on: 27 / August / 2009, 00:48:08 »
Advertisements
Ok, thanks. The actual link was http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#toc5

So basically  : "memory","r1","r2","r3");" means that those things are trashed, right? Since that field is optional, why were they declared there in the first place? The execution is not returned to the C function anyway..
Logged
*

Offline HarpoMa

  • ***
  • 218
Re: Resuming activity from the LED blinker program
« Reply #21 on: 27 / August / 2009, 00:50:16 »
From personal experience there is nothing like porting chdk to a new camera.  It may be worth doing an old camera from scratch to get the idea of all the ins and outs.  That way if you need assistance you can look at the current port and see the answer.

Harpo
Logged
Canon Models - SD300, SD780, & SX210
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #22 on: 27 / August / 2009, 00:54:19 »
Wow, it works now, thanks a lot!

Here is my frankenstein  function, combined from multiple pieces of code, and ugly as hell:

Code: [Select]
void FirmwareStart()
{
    asm(
"LDR     R3, =0xC02200bc\n"
"MOV     R2, #0x44\n"
"STR     R2, [R3]\n"

// looks like idle cycle is required for proper shutdown
"MOV     R3, #0x8000\n"
"idle_cycle:"
"SUB R3, R3, #1\n"
"CMP R3, #0\n"
"BNE idle_cycle\n"

// ordinary startup...

"MOV     SP, #0x1900\n"
"MOV     R11, #0\n"

"MRS     R1, CPSR\n"
"BIC     R1, R1, #0x3F\n"
"ORR     R1, R1, #0xD3\n"
"MSR     CPSR_cf, R1\n"

"LDR     R2, =0xC0200000\n"
"MOV     R1, #0xFFFFFFFF\n"
"STR     R1, [R2,#0x10C]\n"
"STR     R1, [R2,#0xC]\n"
"STR     R1, [R2,#0x1C]\n"
"STR     R1, [R2,#0x2C]\n"
"STR     R1, [R2,#0x3C]\n"
"STR     R1, [R2,#0x4C]\n"
"STR     R1, [R2,#0x5C]\n"
"STR     R1, [R2,#0x6C]\n"
"STR     R1, [R2,#0x7C]\n"
"STR     R1, [R2,#0x8C]\n"
"STR     R1, [R2,#0x9C]\n"
"STR     R1, [R2,#0xAC]\n"
"STR     R1, [R2,#0xBC]\n"
"STR     R1, [R2,#0xCC]\n"
"STR     R1, [R2,#0xDC]\n"
"STR     R1, [R2,#0xEC]\n"
"STR     R1, [R2,#0xFC]\n"

"MOV     R1, #0x78\n"
"MCR     p15, 0, R1,c1,c0\n"
"MOV     R1, #0\n"
"MCR     p15, 0, R1,c7,c10, 4\n"
"MCR     p15, 0, R1,c7,c5\n"
"MCR     p15, 0, R1,c7,c6\n"
"MOV     R2, #0x40000000\n"
"ORR     R1, R2, #6\n"
"MCR     p15, 0, R1,c9,c1\n"
"ORR     R1, R1, #6\n"
"MCR     p15, 0, R1,c9,c1, 1\n"
"MRC     p15, 0, R1,c1,c0\n"
"ORR     R1, R1, #0x50000\n"
"MCR     p15, 0, R1,c1,c0\n"

"MOV     R3, #0xFF0\n"
"LDR     R1, =0x12345678\n"
"ADD     R3, R3, #0x4000000C\n"
"STR     R1, [R3]\n"

"MOV     SP, #0x1900\n"
"MOV     LR, PC\n"
"LDR PC, =0xffc00000\n"
    );
}

Thanks for taking your time to help me.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #23 on: 27 / August / 2009, 00:56:45 »
Quote from: HarpoMa on 27 / August / 2009, 00:50:16
From personal experience there is nothing like porting chdk to a new camera.  It may be worth doing an old camera from scratch to get the idea of all the ins and outs.  That way if you need assistance you can look at the current port and see the answer.

Harpo

What I am trying to do here is a side project of mine. I want to be able to modify the firmware so that I can remove those annoying error checks that won't let me start the camera without lenses, as well as the long exposure hack and possibly other cool things. But it will probably not work in conjunction with CHDK, however some people might find it useful (if I manage to get it to work, that is).
Logged
*

Offline reyalp

  • ******
  • 14125
Re: Resuming activity from the LED blinker program
« Reply #24 on: 27 / August / 2009, 01:44:57 »
Quote from: RaduP on 27 / August / 2009, 00:56:45
What I am trying to do here is a side project of mine. I want to be able to modify the firmware so that I can remove those annoying error checks that won't let me start the camera without lenses, as well as the long exposure hack and possibly other cool things. But it will probably not work in conjunction with CHDK, however some people might find it useful (if I manage to get it to work, that is).
If you succeed in making a generic relocater/patcher for canon ROM code, that would be very useful. However, I'm pretty sure this is practically impossible to do in a way that is strictly correct, and difficult to do in a way that is broadly useful. I've put a bit of thought into this because it would be very nice not to have all the copied inline ASM in CHDK. A big problem is that you have no way of knowing whether a constant loaded from memory is an address or not. Analyzing the code to determine this is non-trivial.

You can't just look for LDR PC, 0xblahblah, you have to handle function pointers that get passed around in registers and data structures too. You can't just assume that everything between FFC0000 and FFFFFFFF is a pointer, because patterns like that are quite common in bit fiddling etc.

Traditional relocators don't have these problems, because the compiler/linker store extra information about which symbols need to be relocated in the object files.

If you do decide to pursue this, I strongly suggest doing your initial development on the PC. The quick turn around time and ease of debugging will make it worth your while. Pick a section of code to relocate, run your relocator on it, and analyze the results in a disassembler. You can use canon ROM code, but you might also find it useful to use some generic ARM code that you can run in an emulator. I'll also repeat my earlier suggestion of familiarizing yourself with existing loaders/relocators.

One final thing to pay attention to is cache coherency... if your copied/modified code is in the data cache but not yet in the instruction cache, things will get very confusing. The arm docs cover this.
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #25 on: 27 / August / 2009, 02:01:29 »
Yes, I kind of know that it is difficult, but my disassembler can already tell which part is code and which is data by analyzing the flow of the program (although it gets confused of the PC is changed through some unorthodox ways, such as using add pc,something).

And yes, I do plan to do it on the PC first, that way I can actually take a look at the code. There is no way I could do it in camera first, without a lot of testing :)

So the way I am planning to do it is like this:
1. Run a search for all the functions, by looking for the stmfd, bl, bx, and so on, then check if the next instruction is valid.
2. If the function apears to be valid, I analyze the code and find the data structures.
3. After hopefully all the code has be analyzed and separated in: data, code, and unknown, I will look in the data and unknown parts for values in the range I am interested and change them.
4. All the values in the unknown portion will be logged to a file for manual inspection.

Sure, it won't be perfect, and some code/data might not be changed properly, but from manually looking at a few canon firmwares, it seems to be relatively doable.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #26 on: 27 / August / 2009, 03:51:21 »
Quote from: reyalp on 27 / August / 2009, 01:44:57
A big problem is that you have no way of knowing whether a constant loaded from memory is an address or not. Analyzing the code to determine this is non-trivial.

Well, let's say the code starts at 0xffc00000 and ends at ffff0000 and you find a memory location that you know for sure is accessed from the code, and holds a value like ffc03620. What else could it be if not an address? Two shorts or for bytes that just happen to match your address range? Even this can be detected, to see if a memory location is accessed as an int, short or char. So if it is an int, what else can it be? Of course, there is a very unlikely possibility for that to be not an actual address, but then someone can manually inspect the code and do a few manual adjustmnets.
Logged
*

Offline reyalp

  • ******
  • 14125
Re: Resuming activity from the LED blinker program
« Reply #27 on: 27 / August / 2009, 04:53:58 »
Quote from: RaduP on 27 / August / 2009, 03:51:21
Well, let's say the code starts at 0xffc00000 and ends at ffff0000 and you find a memory location that you know for sure is accessed from the code, and holds a value like ffc03620. What else could it be if not an address?
Suppose you have
LDR R0, =0xFFF00000
BL some_function

Is the thing passed to some_function a function pointer or a mask that masks off the lower 24 bits ? A real example of this is FFFF0000. There is valid code at that address, but there are lots of instances of that constant that are unrelated to it.

The only way to correctly deal with situations like this would be to analyze the entire flow of the program and see how it is used, which isn't practical. That doesn't mean you can't develop heuristics that are good enough.

Note that even if you can relocate it correctly, you won't be able to just copy all the ROM code to RAM and run it. The size of the ROM is significantly larger than the free memory available after all the other stuff the firmware requires is accounted for.
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #28 on: 27 / August / 2009, 05:01:44 »
Yes, to do it 100% correctly would be almost impossible without a full system emulator and something like valgrind :D
Anyway, we talked before about the memory on the cameras and the conclusion was that there should be enough room in the JPG buffer (at the end). If there isn't enough room, then one option would be to disable the jpg output and rely on RAW only.

But I will take things one step at a time, first the PC relocator, then if it works, I'll worry about the memory later.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #29 on: 27 / August / 2009, 13:38:53 »
After thinking for a while, I came upon a question I can't find an answer for.
Except for data values that change PC, is there really a point to change the other data (pointers) from the old address to the new address? I mean, it's not like the ROM dissapears or anything, so that data is still valid. So long as the code execution doesn't go to the ROM functions, why would we want to change the pointers?
Logged
Pages: 1 2 [3] 4   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal