Making the firmware relocatable - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2   Go Down

Making the firmware relocatable

  • 19 Replies
  • 6495 Views
*

Offline RaduP

  • *****
  • 926
Making the firmware relocatable
« on: 28 / August / 2009, 21:42:38 »
Advertisements
This is a continuation from this thread: http://chdk.setepontos.com/index.php/topic,4129.0.html

I am adding a new feature to my disassembler to analyze the code and find memory locations that need to be modified to make the firmware relocatable. This is not a simple thing, but I believe that it might be doable, so I am trying to see how far I can get.

My platform is an a530 and I am using its firmware dump.

Anyway, my problem now is that I found code such as:
ldr R12,=0x91344
mov LR,PC
ldr PC,[R12]

Do you guys know what is at that address? It seems that there is a table of function pointers or something starting at about 0x91000. Am I wrong about it?
Do you know when that list is populated with values? Is it filled after the firmware starts, or is it some ROM stuff? If it is filled after the firmware starts, by the firmware, then probably I won't need to relocate that list too, which would make things very not fun :/
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Making the firmware relocatable
« Reply #1 on: 28 / August / 2009, 22:32:57 »
If you look at the data initialized from ROM (first loop in the very start of the firmware) a bunch of data is copied from ROM to RAM. This includes function pointers. This is not to say that ALL function pointers are initialized this way.
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Making the firmware relocatable
« Reply #2 on: 28 / August / 2009, 23:03:04 »
Unfortunately, I kind of suck at ARM assembly. I understand the instructions, but it's like when you learn to read, you know the letters but it's hard to put the words together :) I can't find the code you mentioned, but it's good to know the firmware code puts the pointers there.

Ok, now next step is to find if a jump (b/bl) jumps in the middle of code or in the middle of garbage. I determined that MOST of the garbage, if translated as instructions, has some condition flag set (which is normal, 1/16 chance of some garbage to have the condition set as unconditional).
So I am planning to read a few instructions before and after the jump address, and see how many of them are unconditional. If most are unconditional, it means we have code, if not it means we have garbage.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Making the firmware relocatable
« Reply #3 on: 06 / September / 2009, 02:03:20 »
Today I had some time to play with my ARM disassembler/code analyzer part, and managed to use the conditions method in a heuristic way to determine if something is code or garbage. So far, I have no garbage labeled as code, although not all of the code is found yet.

To find the rest of the code, I am going to search for valid stmfd SP! instructions (unconditional only).
The rest of the code is a little bit more tricky, because it is using jump tables. From my observations, some of the jump tables have at least 3 addresses in a row. Those addresses are generally near the address where they 'live'. And using my heuristic code or garbage function, I should be able to find those evil jumps as well.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Making the firmware relocatable
« Reply #4 on: 07 / September / 2009, 01:18:16 »
Another update:
Using my code or garbage function, which I improved to use a multi pass code checking, now I can look at every piece of data and find not only the b/bl instructions, but also the pointers to code.
So far, no garbage is labeled as code, and about 95%+ of the code is found correctly.

I now need to polish a few things.
For example, I found instructions such as:
mov LR,PC
ldr PC,[blah]

Now, my program would stop trying to investigate further, because it assumes that since the PC is changed with an unknown value, all hope is lost. However, there is code after that ldr pc instruction, and since the PC is saved in LR just before, it is safe to assume that the program expects to continue the execution afterwards. So I have to take that into account.

Right now, this is the result of my analysis:
Code analyse complete. Found 578933 code, 35604 data and 434039 unknown.

When I make more progress, will let you know.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Making the firmware relocatable
« Reply #5 on: 08 / September / 2009, 23:51:57 »
I am almost ready to dump all the pointers that need to be modified as a C array. Is there anyone who would like to work with me at this project? I can give them all those pointers, and they can do the relocation itself. If no one volunteers, I guess I can try it by myself, but it would be faster if I can work with someone else.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Making the firmware relocatable
« Reply #6 on: 09 / September / 2009, 02:28:04 »
BTW, is there a jpeg buffer pointer variable in CHDK? I couldn't find it, but maybe I don't know what to search for.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Making the firmware relocatable
« Reply #7 on: 09 / September / 2009, 04:11:48 »
Quote from: RaduP on 09 / September / 2009, 02:28:04
BTW, is there a jpeg buffer pointer variable in CHDK? I couldn't find it, but maybe I don't know what to search for.
Not in CHDK. There are some strings in firmware that reference something like that, but be warned that addresses given in test/debug output may not be the same as actually used in shooting. For example, on cameras with more than one raw buffer address, string CRAW BUF will only lead you to one of them.

The known buffer addresses in CHDK are found in platform/<camera>/sub/<fw version>/lib.c
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Making the firmware relocatable
« Reply #8 on: 09 / September / 2009, 04:44:20 »
Ok, that kind of sucks, because that's where I was planning to relocate the code. I guess I can initially put it in the RAW buffer to check if it at least starts, and hope the initialization routines don't clear that buffer first. Although I guess I can just patch the raw buffer address to make it point to the ROM or something.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Making the firmware relocatable
« Reply #9 on: 09 / September / 2009, 18:23:02 »
Quote from: RaduP on 09 / September / 2009, 04:44:20
Ok, that kind of sucks, because that's where I was planning to relocate the code. I guess I can initially put it in the RAW buffer to check if it at least starts, and hope the initialization routines don't clear that buffer first. Although I guess I can just patch the raw buffer address to make it point to the ROM or something.
Note that the many cameras alternate between two different raw buffers.

Also note that the addresses used for the various buffers are the uncached view of main memory. You'll probably want to put the code in cached address space.
Logged
Don't forget what the H stands for.
Pages: [1] 2   Go Up
« previous next »
 

Related Topics