Sorry in advance for the long post.
I recently had a mainboard die on me while doing som hw-modifications to my 1100D, and ended up buying a replacement mainboard. This, however, is in FactoryMode, so USB connection isn't working normally. This is needed for my use (astrophotography).
Using IDA and a rom-dump from ML, I set on my way to fix this.
As the api call "ClearFactoryMode" present in some cameras isn't (or at least isn't registered) in the 1100D (1.05) firmware, I've been looking through the firmware after a memory/rom address that stores the factorymode setting. I figured that by finding a function which clearly branches depending on this setting, would set me on track to find the address.
The debuglog has these two entries:
766: 1324.648 [PTP] ptpConnectModeChanged:ffffffff -> deadbeef
767: 1324.661 [PTP] ConnectFactoryMode
Which is caused by the factorymode setting. I believe without it it would be ffffffff -> ffffffff and not deadbeef.
The entries to the log file is found in the function at xFF1262E4, where the deadbeef value is read through the address at R1 +x4. Sadly, I cannot find where this function is called from (and thus the value of R1), as the only xref (xFF59AA00) points to a long lists of DCD's followed by function addresses, and I don't know where these are used. I should also note that I understand that this setting alone might not be enough to get my camera out of factorymode, but it should restore normal function of the USB-port (I think/hope).
I should mention that I don't really have any experience with arm, I've done some assembly programming for AVR, and other more high-level languages as well as VHDL, so I'm really on new territory here.
In a hope to shed some light on this, I was hoping to emulate the startup using trix and ida, and this boots until the init fucntion (displaying K288 and so forth in the log), and then reaches an infinite loop in what I expect is the PowerMgr task (xFF1EA7D4). Thus it never reaches the breakpoint I've set in ptpConnectModeChanged.
Is this due to some interrupt driven by a timer used by the task scheduler not being implemeted, or is there something else in wrong? I don't expect the emulator to do wonders, but I was hoping it would get this far.
My alternative is to either compare my rom-dump with one from a healtyh 1100d, or try to get the old settings out of my more-or-less broken mainboard using led blinking or something. It can run the simple blink-tests, but doesn't boot up anything else. Writing these settings into rom shouldn't be hard, at least I found some functions used by enablebootdisk etc that writes a value to a rom address.
If anyone has some hints/tips that would be great. A simple c-file for creating a autoexec.bin for blinking etc also would be nice. I might try using the GDB-fucntion for creating a breakpoint in the camera, and read out the register that way.
And a big thank you to everyone involved in this project, the amount of work you've done is astounding
I'm almost happy my PCB died, so that I could dive into ML 
I recently had a mainboard die on me while doing som hw-modifications to my 1100D, and ended up buying a replacement mainboard. This, however, is in FactoryMode, so USB connection isn't working normally. This is needed for my use (astrophotography).
Using IDA and a rom-dump from ML, I set on my way to fix this.
As the api call "ClearFactoryMode" present in some cameras isn't (or at least isn't registered) in the 1100D (1.05) firmware, I've been looking through the firmware after a memory/rom address that stores the factorymode setting. I figured that by finding a function which clearly branches depending on this setting, would set me on track to find the address.
The debuglog has these two entries:
766: 1324.648 [PTP] ptpConnectModeChanged:ffffffff -> deadbeef
767: 1324.661 [PTP] ConnectFactoryMode
Which is caused by the factorymode setting. I believe without it it would be ffffffff -> ffffffff and not deadbeef.
The entries to the log file is found in the function at xFF1262E4, where the deadbeef value is read through the address at R1 +x4. Sadly, I cannot find where this function is called from (and thus the value of R1), as the only xref (xFF59AA00) points to a long lists of DCD's followed by function addresses, and I don't know where these are used. I should also note that I understand that this setting alone might not be enough to get my camera out of factorymode, but it should restore normal function of the USB-port (I think/hope).
I should mention that I don't really have any experience with arm, I've done some assembly programming for AVR, and other more high-level languages as well as VHDL, so I'm really on new territory here.
In a hope to shed some light on this, I was hoping to emulate the startup using trix and ida, and this boots until the init fucntion (displaying K288 and so forth in the log), and then reaches an infinite loop in what I expect is the PowerMgr task (xFF1EA7D4). Thus it never reaches the breakpoint I've set in ptpConnectModeChanged.
Is this due to some interrupt driven by a timer used by the task scheduler not being implemeted, or is there something else in wrong? I don't expect the emulator to do wonders, but I was hoping it would get this far.
My alternative is to either compare my rom-dump with one from a healtyh 1100d, or try to get the old settings out of my more-or-less broken mainboard using led blinking or something. It can run the simple blink-tests, but doesn't boot up anything else. Writing these settings into rom shouldn't be hard, at least I found some functions used by enablebootdisk etc that writes a value to a rom address.
If anyone has some hints/tips that would be great. A simple c-file for creating a autoexec.bin for blinking etc also would be nice. I might try using the GDB-fucntion for creating a breakpoint in the camera, and read out the register that way.
And a big thank you to everyone involved in this project, the amount of work you've done is astounding
I'm almost happy my PCB died, so that I could dive into ML