Switching cards between cameras is an interesting question. My first thought was: "cards are cheap", but that's probably because my cam only supports SD. If you have a 32 gig SDHC or eyefi, I can see that point.
cfg handling is something that could use some attention anyway, so that would be worth keeping in mind if anyone decides to re-work it.
Whim is right, the cams that require encoded diskboot.bin would definitely require their own bootloader.
I think you could do a universal loader (aside from the exception above), at the cost of increased the boot time. As others have said, this could be a major downside. How big a deal it was would depend somewhat on how big your loader had to be. If you are lucky, it could be only a KB, which wouldn't be noticeable.
Your initial universal loader would
- figure out what camera it is on. It's not clear what the best way to do it is, but I'd start with a table of address/byte squence that are unique to each camera. I would start out with platformid and firmware version string, which should be sufficient and relatively easy to find. Note that this would allow you to avoid searching ROM or hashing large parts of it, you'd just walk through a < 100 entry array comparing a couple of words for each. The time to do this would be inconsequential, especially compared to say reading a single block from the SD card. You might have to figure out the ROM start address first (by checking CP15, or looking for strings at FFC00000) to avoid invalid memory accesses.
- compiled in would be the minimal set of entry points required to load a file (indexed by the same index as your ID table), for each camera. This may be difficult, because the normal functions we use for file IO expect the OS to be loaded. However, the initial boot code that finds and loads diskboot.bin might be usable. It obviously understands enough FAT to find diskboot.bin, ps.fir and a few other things in the root, long before the full OS is booted. Look around FFFF0000 for this code.
- instead of doing copy_and_restart, your loader would look up the required chdk image (which would consist of the core and the restart code) and load that instead.
- you'd have to do a bit of shuffling to avoid over-writing yourself.
Another variation is possible, which might be more efficient:
- In each regular CHDK image, include the ID/loader code. If this is relatively small, it won't add much to load time, and it can be discarded before the CHDK fully boots, so it won't take away from available memory.
- The first thing each image checks is whether the correct platformid and version string are at the expected addresses for this camera.
- If those are correct, it boots the code that was already loaded with this diskboot.bin, essentially using the normal boot process.
- If it isn't correct, it tries to find the correct one on disk, and copy that to diskboot.bin.
- If it's hard to get write functions in the loader (quite possible, the functions used by udumper aren't suitable) you would instead load the image as described in the method above, but signal that it needs to do the copy. This could be done by modifying a variable in the loaded image. Once CHDK was booted, it would take care of the copy (although you'd have to work around the fact that we hide diskboot.bin under a dummy device driver in h_usrRoot.)
