SDRAM to FLASH stub
I have created a short assembler routine that moves a 512 byte block from SDRAM to FLASH. I tried several variations trying to get a read from flash but currently I can only write to flash. The following stub will read from $200000 in SDRAM and write to $200000 in FLASH. http://camerahacking.mine.nu/phils/demanufacturing/pv2/www/brite_eye/flash.s http://camerahacking.mine.nu/phils/demanufacturing/pv2/www/brite_eye/flash.pv2

Cool. Awesome work. Unfortunately it didn't seem to work on my battery drop fried camera, although it does work on a good camera. FWIW, I looked in the disassembly of my firmware.bin and found that the one place that refers to $f20d and the two places that refer to $f209 are seen as data instead of code. What are the functions of those two registers?

Awsome work brite_eye!!!! My plan of putting the devkit out there and letting someone else do the hard work has come to fruition! :lol: I'll have to update the devkit with examples for all the stuff we know so far... strobe control, reset register, LED and shutter control, and now SRAM->SDRAM and SDRAM->FLASH transfers! (with attribution to you on those ones, of course!)

zapped, that's odd they were in code in my 6410 disassembly - are you sure you disassembled a Red 6410 firmware? Actually f209 and f20d asic codes may not be necessary - more experiementation needed. I do not fully understand why it can write to flash and not read from flash - one theory is that somehow fat directory is made available in sdram once during initialization and only writes are needed after that (or I just didn't find the right asic register to set to 0 instead of 1). This is a risky painful process and I am hoping others will help - in the end we may be able to write a much better firmware than generated by SMaL's banked C routines.

I should have mentioned that I have only the 6520_28 and 6550_2B cameras and I am using the firmware from 6550_2B. In order to make it disassemble correctly, is a change needed to the comments file or to the disassembler?

In a word, yes. I can send you a copy of my unfinished comments for the 6550. I only have banks 0 through 2 mapped.

Major Discovery!! data exists above $400000 in SDRAM! I can dump SDRAM above $400000 using flash.s! And first block contains FAT ($7400) - offset by 16 FFs then a 0101. So my theory about not needing to read flash may be correct. Can someone else verify using sdram.s (changing direction)? Running sequential iterations of flash.s seems to corrupt flash at location in program, but a simple pv2tool format restores it to FFs. I uploaded a newer version of flash.s, .pv2 to binary's site up above.

After 2 sleepless nights - I'd really appreciate it if a new "hacker" could combine both sdram.s and flash.s to dump complete 8mb sdram into last half of flash. It would also be nice to have an sram dumper to obtain bootloader code from an intentionally bootloadered camera. :idea:

great work!!! I never followed the sdram/flash routines.. I just figured out the calling parameters and trusted it did its stuff.

data exists above $400000 in SDRAM! Wrong - Sorry. Stub seems to execute and move data without any error and so does PV2Tool when camera has been unlocked. But after several trials with PV2Tool it appears that range from 4M to 8M is a mirror of 0M to 4M. I used PV2Tool on unlocked camera with transfer size of $200000 and LUN = 4. My assumption is that ASIC (as eye see) is undressing or dressing behind the blinds.