I'm quite new here, and up to now I just tried the linux pv2tool... For me the sdram scanning also didnt work: Attempting download of SDRAM for keyscan Failed at retrieving memory Scanning SDRAM for keys WARNING: (unlock_camera.c, 895): No keys were found maybe i'm doing wrong, maybe it is the program.. I followed this method: http://home.comcast.net/~jshamlet/intro.html and I heard the 2 beeps I might try the windows version tommorrow, if I find time ...

PV2Tool for linux, unlock_camera.c in function ReadMemory is: <br>Write(&cmd, sizeof(camera_command), SHORT_TIMEOUT) <p> This should probably be: <br> Write(cmd, sizeof(camera_command), SHORT_TIMEOUT) <p> Without this the write never works as it's sending the pointer to the cmd instead of the cmd. Haven't got PV2tool/sdram scan to work yet though (now Read returns 0).

Hmm.. I don't know if I should unlock the camera in Windows then, or wait for a fixed Linux version.. I really would like to help getting the linux version working.. But I can't help anymore when I will unlock it in windows, right?

Linux is debian stable (3.1), just installed. I've switched to using the uhci kernel module instead of the newer usb-uhci kernel module. Also I'm using LD_LIBRARY_PATH to point to a later libusb (libusb-0.1.so.4.4.3 instead if libusb-0.1.so.4.4.2). At this point I managed to retrieve some possible keys with "scan SDRAM for keys". Trying the key was sending a command string with one byte "unknown" set to 01 instead of 00. I added a memset(&cmd_get_challenge, 0, sizeof(cmd_get_challenge)); before the call to createcommand in Unlock (and one before the 2nd createcommand too just in case). At least once I got the key matched and unlock succeded msg. I tried downloading the flash which looks like it might be ok but I haven't looked at enought to be sure.

I've a newer gentoo kernel based on 2.6.15 I just can find a libusb-0.1.so.4.4.2 which belongs to libusb-0.1.10a So, I should probably update to libusb-0.1.11.. The kernel module is EHCI because of usb 2.0 and OHCI because of 1.x compatibility

The flash image I downloaded looks like the same 128K over and over (total 16M bytes). This does look like what I'd expect to see in the first 128K of the flash. I'll be looking into this. Looking at readwrite.c:create_command, I think it needs to zero out the command area first and have the data == NULL case changed. Currently the memcpy for the data == NULL case appears to copy garbage (since sizeof (cc->data) is 14 bytes long and zeros is only 4 bytes long). I haven't seen this garbage case occur, this is from looking at the source.

ReadFlash wasn't sending starting sector for each 128K read. I changed the obvious line in ReadFlash to: *((u32 *) cc.data) = cpu_to_le32(sector); I now have a 16Mbyte file which isn't repeating 128K byte chunks (don't know if it's right though). I've added a memset to zero at the start of create_command and removed the memset's I had added in unlock_camera. Unlock only works sometimes and I'm not sure why it works or fails. It usually fails, but sometimes works. Fails look like: create_command: 4c 61 4d 53 1d ba ab 1d 80 00 00 00 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 create_command: 4c 61 4d 53 1d ba ab 1d 80 00 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Requesting challenge from camera Write(001f) 4c 61 4d 53 1d ba ab 1d 80 00 00 00 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Write returns 31 Read 1 failed rc 0

Hm ok, is there a cvs of the pv2tool for linux on sourceforge? Maybe you could contribute your progress there.. btw: thx for doing this :wink:

I'm still not sure my 16M flash image I downloaded from the camera is good, but I'm looking at two pictures from it and they seem ok. I used my own fat file system kludge code to extract the picture files from the flash image file. (No need to mess with the GTK or USB code). I compiled the dcraw out of pv2fetch-0.8. Since this is on Linux I used the system libjpeg (and no lcms). So only dcraw.c and the routines in the smalraw directory needed compiling.

hm you are still doing any work? and is it available on sourceforge?

I've succeded in getting pictures off and deleting them from Linux. The USB interface seems intermittent (each time usb_open is called the following USB operations either fail/timeout or work, usually fail). Once it works it stays working for the session. I've put in code to make a few retries but it still takes a few tries to work. Oh, this is using libusb-0.1.12 and either the OHCI or UHCI driver (not USB-UHCI) in kernel 2.4.20-43.9.legacycustom. I tried kernel linux-2.6.15.6 but it didn't seem different. This still needs some cleanup plus more operations like find key (sdram download), flash download, run code, upload/download general file(s). I don't have an id on sourceforge... Where are the la-*test*-('") firmware.bin comments files kept?

Can you post a patch against the availible pv2tool on Sourceforge? I may be able to get it sent up to them, having an account.

cho, can you send this file to anyone, or even post it on a free hosting site (ie rapidshare.de)

Any word from cho? I'm new here, but have been lurking around for a few months. I've messed with the code a little, mostly trying to get a reliable connection (like cho mentioned that it usually won't respond to requests)... are we the only two people that it usually fails for? For me it's kinda strange because I'll click take pic and nothing will happen, then I'll click open cam a bunch of times and all of a sudden it'll start taking pics every time open cam is pressed :? . I'm wondering if it has something to do with the USB urb, like maybe we should use usb_submit_urb() instead of usb_control_msg() (since it's an asynchronous message). I also couldn't find where ->unknown was initialized, so it could be sending some weird value instead of 0x00, but when I initialized it, it didn't seem to work any more reliably. DogP

some patches..
I've uploaded some patches to pv2tool-linux-0.1.tar.bz2 which include some small fixes plus some debugging code. See http://rapidshare.de/files/24966850/debug-20060604.patch.html Someone might add this to sourceforge.