DataGhost
Ok, I'm new here (in the DSLR section) so I started looking at this stuff about 15 minutes ago.
Seklth
@jeff666
eventproc_EdLedBlink, what store dword to mem - not worked.
What is the exact address you found for that function or how do you call it? I don't have that particular name in my IDA dump, maybe this was done by your signatures or scripts but I'm not sure. Anyway, I may know how to call it or what it does, unless you already use that method.
Oh and.. how many LEDs are on the camera and how many are lit while running your code?
owerlord
the function list is exported with Seklth idc scripts, and imported by them also. (see attachments in this thread). on the body of 400D are only 3 leds: power led, CompactFlash access led, PTP (print direct) led.
I do not know witch is the EdLed - from the source - becose it didn't work.
while running the code the power led is led. and when I initialize the system the CF led blinks a bit.
DataGhost
Okay.... I guess I'm a little bit blind then, I still don't see eventproc_EdLedBlink in the function lists I found in this thread and the idc files don't really look like they're going to identify it. Can you verify that you have that function in your list and export it or tell me the address?
owerlord
Sorry - accidently they are not functions - so idc didn't export them. here thy are:
ROM:FFAFCC78 eventproc_EdLedOff
ROM:FFAFCCA4 eventproc_EdLedOn
ROM:FFAFCCD0 eventproc_EdLedBlink
DataGhost
Ah, ok. Yes, those are the same ones I found and IDA identified them as loc_.... so indeed not a function. Anyway, did you also try EdLedOn and EdLedOff or did you only try EdLedBlink? If you tried them all, they probably confirm my theory. Those functions give me a PostLEDMessage (present on compact cameras) feeling, so they probably tell the OS to turn on/off or blink a specific LED. If the OS isn't running anymore... well.. do the math. I guess you'll have to search for the addresses 0xCAF0 and 0xCAD8 (or 0xC0210014 and 0xC0220000, their respective values), as they seem to tell the OS what to do.
Equivalent, abbreviated C:
void EdLedOff() {
*((long *) 0xC0210014) = 0;
*((long *) 0xC0220000) = 0x44;
}
void EdLedOn() {
*((long *) 0xC0220000) = 0x48;
*((long *) 0xC0210014) = 1;
}
void EdLedBlink() {
*((long *) 0xC0220000) = 0x48;
*((long *) 0xC0210014) = 3;
}
owerlord
yes. I know what it does. I done the asigments in memory without calling the functions.
It didn't blink or lit anything. Before or after OS rewriten procedures. Even after the EdLed register procedures and memory initializations.
Seklth
test other addresses from this function: sub_FFAFCAF0
DataGhost
They might do other things, though. Anyway, Maybe you could try setting 0x46 into 0xC0220000 (or another addresses) since that's the value other cameras usually use to turn on a LED.
Seklth
Hehe, DDD - it is DustDeleteData
@owerlord
if comment call "eventproc_Startup();" - menu not show?
Seklth
@owerlord
>char* nm = "A:/TST.BIN";
correct - A:\\TST.BIN =)
owerlord
Oh sorry for not writing*. see you figured out the same ideas.
@Seklth :
yes. DDD is dust detection code - what why I didn't want to run it without being surten that I have the system up.
DDD uses / not \ - I would stick to that.
yes Startup task wake the menu - comment it - and nothing will apear.
@DataGhost
Sorry for delay* - I tested other value (flags) after my earlyer post - 0x46 works on the PTP led.
*)"American Gangster" - quite good.
DataGhost
Nice, so you can now light the PTP LED? Please do tell how, so other people can benefit from that. This might also be usable for dumping the 40D (main firmware in the update file is still encrypted). Apart from that, as said before, that LED will be a great help and your only indication whether or not your code ran succesfully for some time.
owerlord
it's just like:
*((long *) 0xC0220000) = 0x48; to light.
*((long *) 0xC0220000) = 0x44; to dark.
If the 40D have the same adresses - there is no problem to do a led-firmware dump.
I made a wierd experiment:
I inserted light-dark instructions on the path from romStart to Startup task, like:
romStart - light
usrInit - dark
usrKernelInit - light
usrRoot - dark
AppInit - light
Startup - first dark
Startup - after calling eventproc_Startup - light
Obserwation:
blink after loading... disapears. then dark. even after the menu apears. wierd.
owerlord
this time:
romStart - light
Startup - dark
Srastup - light after eventproc_Startup.
blink after loading - then nothing. I think it means:
1. all the code is runned without delay. i just wakes the lcd and cf with delay.
2. the eventproc_Startup don't return.
DataGhost
Why didn't that work before, then? ???
Anyway, I suggest lighting the LED only and just once. Recompile your program every time so you can see where execution stops. You can then narrow it down. It's not really reliable to do it like this, because you might not see how many times it blinks and some code may be skipped so that some light/dark switches may never be executed. Even then, I suggest adding a delay, since other code may turn the LED off again (this could also be happening in Startup, for example). Just make a simple loop which does about ten million iterations of nothing, maybe more, maybe less (figure that out yourself) and turn the LED off after the loop finishes. If you're working in ASM, you should do something like
STMFD SP!, {R0,R1}
LDR R0, =0xC0220000
LDR R1, =0x48
STR R1, [R0]
LDR R1, =10000000
loop:
NOP
NOP
SUBS R1, R1, #1
BNE loop
LDR R1, =0x44
STR R1, [R0]
LDMFD SP!, {R0,R1}
Response to last post:
1. Code is likely to execute very fast so you might not see the LED turning on or off
2. It's possible that some functions (tasks) don't return until they finish. Maybe it contains some sort of infinite loop to ensure certain things happen
And as I said, the LED is also controlled by the OS so you'll need the delays to be sure.
By the way, I don't know what your code looks like or how experienced you are, so I may be saying things you already know.
owerlord
DataGhost
By the way, I don't know what your code looks like or how experienced you are, so I may be saying things you already know.
You are - don't worry about that 😀 The code is nearly whole in C (GNU not DIAB 😀.
If I'm thinking right: startup don't exit and it turns off the led. I don't know where - and I don't know why it don't exit.
I tested write file -> eventproc_Startup, in place of eventproc_startup -> write file. It didn't work.
The cf driver initialization have to be in the Startup.
I wouldn'd want to rewrite the start-up - becose I didn't identyfied most of the functions there. but it looks like the only method to get going.
owerlord
Analysing the startup. found: Install_mbm29dl64df - I think its Fujitsu 3V memory 😀
> Ok, I'm closing for today. If somebody identyfie some of the Startup proc's I'll be thankfull.
Seklth
@owerlord
maybe you also test this restart?)
code you HAVE RUN on your dslr
And rename eventproc_Startup to task_Startup))
Alse function, that only create file - FF95D674 task_CFTestTask
owerlord
anybody know how to actualize xrefs in IDA? When I add a segment of memory and so. some times IDA don't print all the xrefs to the place in memory.
Seklth
Maybe run this IDC function help:
AnalyseArea(MinEA(),MaxEA());
