Hardware addresses - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1]   Go Down

Hardware addresses

  • 4 Replies
  • 2757 Views
*

Offline RaduP

  • *****
  • 926
Hardware addresses
« on: 22 / March / 2009, 19:42:04 »
Advertisements
I would like to play with an oscilloscope and a broken camera, and test all the ports to see if I can find something useful. For example, the lens motors, USB wires, and so on.
I looked at the LED blinker source code, to see how it works, and noticed this code:
Code: [Select]
#define LED_AF 0xc0220080
#define LED_PR 0xc0220084

void led_on()
{
    volatile long *p=(void*)LED_PR;
    *p=0x46;
}

void led_off()
{
    volatile long *p=(void*)LED_PR;
    *p=0x44;
}

I am not interested by the rest of the blinker application, for my purpose.

Now, the address for the LED looks pretty random, and most likely hardware dependent.
What I have in mind is to write a program that tries every memory location (above where the code is), and connect an oscilloscope to each output, then run the program and notice if anything changes. Obviously, this way I can't detect the memory location, only if a hardware port can be controlled by a memory location. Then I would need to find some way to stop the program execution when the signal happens, and somehow dump the memory location. For that, I guess I would need an 'in' port, which I need to constantly monitor, and a microcontroller.

Anyway, do you find any problems with this strategy? Please note that I don't care too much about damaging the camera, since I plan to buy a broken camera anyway.
And another question, how was the location of the first LED that was used to blink the firmware found? Is there any logic behind the hardware address?
Logged
*

Offline reyalp

  • ******
  • 14125
Re: Hardware addresses
« Reply #1 on: 22 / March / 2009, 21:13:18 »
I would think scanning the firmware for references to 0xC0****** would be more productive (keep in mind these are frequently accessed as a base + offset, so just scanning for literal values won't do it. Also keep remember that ARM frequently builds immediate values with adds and shifts) It is likely that a specific sequence of actions is required to use many of the hardware devices, so just spamming all the MMIO addresses may not tell you much. It is also likely that specific bits do different things, so just trying a single value would tell you much.

I'm not sure how the LED addresses were originally found, but they vary between cameras and aren't terribly hard to find from disassembly if you have a known camera to compare to. Even stuff that isn't already known in another camera can be found via strings etc. If you want to know how to operate, say, the lens controller, you'll probably need to reverse engineer that code anyway. So you might as well get the whole thing that way.

If you do want to use your approach, you could easily monitor the USB power or one of the switches to know when something is found. Most of the code you need can be found in the platforms kbd.c
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Hardware addresses
« Reply #2 on: 22 / March / 2009, 21:46:15 »
Well, the problem is, I don't have a working dissasambler. I tried the GPL way a while ago, but for some reasons I couldn't get it to work. My way, I think, it's easier to find addresses, provided that some devices don't require an elaborate communication protocol.
For example, the lens controller might require timing and some serial data, not just set a pin on high to move the motor, read another pin to see if the optic transcoder indicates that the lenses are fully extended.

I have virtually no ARM experience, so I have  aquestion: What happens if you try to read/write to unallocated memory? Do you get some sort of page fault exception?
Logged
*

Offline reyalp

  • ******
  • 14125
Re: Hardware addresses
« Reply #3 on: 22 / March / 2009, 22:05:31 »
Doing what you propose strikes me as far more complicated than getting the GPL tools to work. In any case, you have very little chance of doing anything useful with the results without some amount of disassembly.

You can determine which addresses ranges are valid by examining the code that sets up the MPU, or by querying the system coprocessor. See this thread http://chdk.setepontos.com/index.php/topic,2139.0.html
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Hardware addresses
« Reply #4 on: 23 / March / 2009, 00:05:52 »
Yes, it is obviously more complicated than getting the GPL tools to work, but I think it is less complicated than getting the GPL tools to work AND looking at all the code, and understanding what's going on. Besides, it is always useful to know the memory location involved with what you are interested in :)
Logged
Pages: [1]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal