Yes, I'll do that after I finalized it. In the meantime, you can start locating and/or redirecting some functions... I posted a .txt file with a commented part of a subroutine, that's the stuff that happens in the S5. I found it by searching for 0x55, you should see something happen with 0xAA and 0x1FE/0x1FF nearby. It'll probably look quite similar to the S5 code. Once you've located that, you'll have to find all references to that subroutine (view->graphs->xref to, the button should be on the toolbar as well but then you'll know what it looks like
) and you have to relocate them all... at least, I do not know a better way of doing it. That's the bare minimum you need to you. You might notice a *LOT* of functions as some sort of web (
http://stack.dataghost.com/S5_xref_to_MBR_parser.png), that all points to a sub which points to a sub which points to a sub which basically reboots the camera and has nothing to do with the code you're looking for. You'll have to edit the graph file (you can save it from the menu and reopen it by passing it as a commandline arg) to get just the useful bits (
http://stack.dataghost.com/S5_xref_to_MBR_parser_better.png). I actually made a mistake in doing the XREF thing, so all graphs I uploaded so far point to the wrong subroutines, although the proper one is called from that one and there are no other xrefs. In one of the graphs I mistakenly 'corrected' it with yet another wrong subroutine, but I don't need it anymore. Keep that in mind if you want to use my graphs.
Also, you don't need an SHDC card to test it. I have two cardreaders, one can read SDHC and the other can't. The latter one has a write-protect bypass and is hooked to my server, so I preferred using a 2GB SD card instead. Just create a partition table with a small FAT16 partition and a large FAT32 partition, create the filesystems and you should be fine. Put some pictures on them that'll allow you to instantly see which partition is loaded so you don't have to go into the menu
As for the SD Lock, did you get that bypassed yet? If not, I used my boot-delay to be able to switch the SD card (or unlock it
) just before the (temporarily hooked) diskboot subroutine. I modified my boot-delay to light up a different LED inside the diskboot subroutine. What I did next was... boot the camera, see if the second delay is called. If it is, you know that the code is actually executed. Now, boot the camera again, take out the SD card in the first bootdelay, unlock it and put the card back in there. If the LED doesn't light up now, the sub already returned so you'll be able to guess what code is responsible for that, and eventually which address is responsible.
Be warned, though, the first three ops in the diskboot subroutine (after saving registers to the stack) actually test to see if the subroutine was executed from the firmware. I guess it gets relocated somewhere or they did some debugging with that and forgot to comment out that code... anyway, uncomment those three lines or it won't work
Oh yeah, the insane amount of code you need to copy to make this work (I'm at about 1800 lines of ASM now) causes the assembler to confuse itself. You need to add ".ltorg" somewhere to fix it, it's probably best to do that at the end of each subroutine, as that is the same layout as in the firmware.
So.. that is if you want to try it the hard way, although you do have to reproduce a large amount of these steps, I think. It'll probably all be a lot easier when I'm done with the code and upload it, possibly tonight (I'm in your timezone) but I can't promise anything. I do get the firm update menu when I put a PS.FI2 file on my SDHC card, but we do need all this code for autoloading. All this combined doesn't even seem to add a large delay to the boot process, the only extra delay I have is the debug led at the beginning
Oh yes, there is just one downside to my method, though... Windows won't be able to access the FAT32 partition on the SDHC card this way. For removable devices, it refuses to read anything else than the first
listed partition in ANY way, even through the disk manager. It also ignores the partition type and filesystem, it just reads the first partition in the table, regardless of it being readable. Other methods for possibly circumventing this problem, i.e. by using a GPT, are carefully thwarted by not supporting those on removable media. It works fine on Linux, though, but I'm sure there are plenty of Windows users around here as well.
Now I said 'first listed' partition, if you switch both partitions around in the MBR, Windows will read the correct one. Unfortunately, the camera shows the exact same behaviour, so it is not possible (as far as I know) to construct an SDHC card with a large FAT32 partition that is both readable in Windows and bootable to the camera. The only workaround would be to write a clientside application which switches the partitions around in the MBR (annoyance), or by writing a driver. Some card manufacturers apparently have software available to mark the card or reader as non-removable media, but I have been unable to locate such a tool as of yet.
