I was finishing up the port of morcheeba's pv2mod for Liunx yesterday when, by trying to be cautious ironically, I managed to corrupt the firmware in my red camera. I then spent the rest of the day probing the bootloader to see if I could work out what it was expecting. Here's a quick summary - more detail will go on my PV2 page when I get a chance to write it up:
* It is still using the same VID/PID in the bootloader mode (this matches the fact that the driver I found did not have a separate entry for the bootloader on this camera
* When read using the $52 method it will return something (initially it was firmware.bin, but not any more on my camera). Also, the status back is $60 always. I suspect that this is another example of the buffer overrun type thing that happens before authentication.
* Writes using the $52 method seem to go into RAM, even with the LUN set to 1, and can be read back again. I cannot make them go to flash though (reset causes it to revert to the broken image). Always returns $60 code as well. Again, I suspect that the writes are just going into scratch space so that it doesn't stall the bus.
* Reads using the $26 command do something different: with lengths that are not multiples of 256 it returns all zeros and stalls. With lengths of 0x100 through 0x3f00 it returns $61 and lengths of 0x4000 up it returns $62. I found the 0x4000 number in the disassembled FIRMWARE.BIN for command $26 as well, so this seems to be the length limit on the $26 commands.
* Writes using the $26 command to LUN 1 generates a beep & a $b1 error always. The length doesn't seem to matter, so I am assuming that the failure is something before the length is checked (must be a command format problem).
* Writes using the $26 command to LUN 0 generate a high pitched beep and it then seems to reboot (guess I overwrote something the bootloader was using!)
* It does not seem to be using the $80 challenge/response.
Something I did has changed the contents of an initial read, but since I have no idea what that is returning, I suspect that this might not be very meaningful.
Conclusions so far:
1) Error $60 is telling me the command was not recognised (so $52 and $80 are both unrecognised by the bootloader; $26 is recognised).
2) The $26 command is the key; this was based on a hunch from disassembling the Mac OS X Foxz driver (the symbols are all in there), and noticing that the firmware update method in the driver is using $26 as its command. I will try to test some of the other commands too (such as the synchronize and reboot commands I found in the Foxz driver). Need some more work to try to decide what arguments they take though.
), Foxz2 only thinks it is.. I think most likely, the Foxz2 driver is reading a bad return value from the camera immediately on boot/install, and getting the notion from there on that the camera is in bootloader mode, even if you unlock it later. Strange because the Foxz2 sends things back and forth to the camera periodically all the time. I have noticed that after Foxz2 had a crack at it, mine would return $64 to commands even if it were unlocked by hand, preventing me from ever getting pictures from it (almost always 'bootloader mode', or just a BSOD whenever both drivers were installed at once). Problem solved 'for me' by killing the authentication in firmware of each and re-uploading it with the latest PV2tool.