TX1 Firmware dumping

[Microfunguy]

A quick check of memory-mapped I/O locations 0xC0220000 to 0xC0220100 fails to find any LED locations.

If I do a wider search, is there any danger of causing damage to other hardware components  in the camera ?

A similar test on the A620 confirmed the code basically works (and the LED's are at the locations we already know) but it also produced a strange sound from some device.



David

[ewavr]

A quick check of memory-mapped I/O locations 0xC0220000 to 0xC0220100 fails to find any LED locations.
If I do a wider search, is there any danger of causing damage to other hardware components  in the camera ?
David

I cannot give advice.
In my A710 I make search from 0xC0220000 to 0xC022FFFF  - without camera damage. But there is always a risk

If LED location search fails, remains two methods: universal dumper (described somewhere in this forum) and "power consumption" method (VERY slow, it was used for G7 LED location search).

[Microfunguy]

two methods: universal dumper (described somewhere in this forum) and "power consumption" method (VERY slow, it was used for G7 LED location search).

Thanks.

I will try to find details about those two methods.

To turn possible LED locations on/off we use *led=0x46;   and  *led=0x44;


Why ?

How were those values found ?


David

[ewavr]

To turn possible LED locations on/off we use *led=0x46;   and  *led=0x44;
Why ?

It is secret of DIGIC  But TX1 can use "inverse" schematic - try 0x44 instead of 0x46 (and vice versa).

How were those values found ?

From firmware analysis (first firmware was decrypted from "firmware update").

[Microfunguy]

I make search from 0xC0220000 to 0xC022FFFF  - without camera damage. But there is always a risk

No. nothing there.

TX1 can use "inverse" schematic - try 0x44 instead of 0x46 (and vice versa).

No, that did not work either (over that address range).

remains two methods: universal dumper (described somewhere in this forum) and "power consumption" method (VERY slow, it was used for G7 LED location search).

Well, it may be slow but it did work.

Was that published in this forum or DPReview ?



David

[DataGhost]

I suggest searching in reverse as well (0xC022xxxx -> 0xC0220000) and from several different starting addresses (device will shut down if you enter non-existing memory). I have found out that, on my S5 at least, the camera could shut down when setting the wrong addresses. I encountered it when doing this manually with the keypad, before the LED addresses (although I did "*led |= 0x2" instead of "*led = 0x46", I believe). It could be that the camera already shuts down before you find the actual addresses.

Edit because of new information below:
Hm, I guess it's still VxWorks then? I'm used to DryOS and have never used the firmware update feature before, else I'd have known the power led stays lit.

[cybercom]

Hi all,

What's happening so far is that the TX-1 sees the ps.fir file on the card saying, update 1.0.1.0 -> 1.0.1.0?

When I tell it OK, the screen blanks after about a 1/10th of a second. The Power LED stays lit. All keyboard functions are inoperative for 13.8 secs at which point the camera turns off.

Nothing blinks, makes noises, rattles or hums.

If I then turn the camera on again and go into Record mode it functions normally.

vers.req returns:


Canon Powershot TX-1
P-ID:3100   NT   V  (Looking at another listing I saw, I'm wondering if that's 310 letter O ??)


Firmware Ver   GM 1.01b
No Error
Mar 23 2007   11:29:53

Adj Ver.027.001

SubCPU Ver 1.02

Total Shoot xxx (number depends on the camera - I have four)


I have two AC supplies, so can try any method, however slow to obtain a dump and could actually do two at a time for verification.

Any and all assistance gratefully accepted!


TIA,

~~~~~~~~~~~~~~~~~~~~~~~~~~~

<")%%%><<

[ewavr]

Was that published in this forum or DPReview ?

Source of "universal dumper" was here - http://chdk.setepontos.com/index.php/topic,221.msg2740.html#msg2740 (and read all in this thread).
Some comment: if camera is VxWorks based, filling  memory with zeroes is not necessary.
About "power consumption" method: sources never have been published, only some speculations and results in russian forum. If it is interesting, I can publish them tomorrow.

[Microfunguy]

Source of "universal dumper" was here

Thanks, I had already researched that, I meant the 'power-consumption' method.-

If it is interesting, I can publish them tomorrow.

That would be very useful, we do not have many options 



David

[Microfunguy]

All keyboard functions are inoperative for 13.8 secs at which point the camera turns off.

Aaahh .. that is slightly different to 'Must wait for timeout to shut off camera.' (private email)

I took that as meaning that after time-out you could then shut-off camera.

If you mean the camera switched itself off , Data Ghosts' comments are relevant.




David

[cybercom]

[jetzt]

I don't really know much about all that, but I'll have a guess:   

Is empty.bin on the sd only a 0 byte file?

I think you have to copy the full 8MB of zeros to sd card, otherwise you won't see anything in file browser afterwards,
as the dumper doesn't change the MasterFileTable.(How I understood that topic.)

* Copy to card file empty.dum from archive (8Mb of "0").

Open Notepad and save empty file on root of SD card as:

empty.dum

File type = all files

Edit:
If that's right you could also try to open your whole sd in a Hex-viewer and compare that to an emty one.
( )(comparing can be replaced through a text search for let's say "Wind" or "canon" or something like that.)

[ewavr]

-deleted message-

[jetzt]

Hmpf. - Why am I that curious? I always want to know what's behind these -deleted message-.
Did you want me to erease my post, is it that stupid? It wasn't about my post? I posted before you could post?

[ewavr]

To jetzt:

Because I cannot erase my useless message, I change it body to -deleted-

To cybercom and all:
Attached src & 8 bins (sic!) of "universal" dumper.