Author
Topic: Canon EOS 1300D / Rebel T6 (Read 71014 times)

Modelling the ROM as IO has just gone over my head complete, so assuming I cant figure that out (yet, im learning) I might continue trying to figure out what might be being mishandled to result in the Assert call.

Yes, that was pretty difficult, as this one requires detailed knowledge of how ROM is configured, and how to do that in QEMU. I think I've figured it out last night, but had to change the ROM layout on all models. This approach appears to break other functionality (e.g. 60D no longer boots), but also gives interesting insights on how ROM reflashing is done (and allows one to implement its emulation, since the ROM addresses appear to behave like I/O during this process):

A simpler approach would have been to patch the ROM manually (hardcoding the flash model ID at those addresses where the firmware expects it). Unfortunately, that appears to lock up the bootloader.

A third approach would be to patch the affected function in GDB (see e.g. 700D - patches.gdb) or in ROM (see DIGIC 6 models, but that would remove the ability to run unmodified autoexec.bin's later, since they do a checksum of the ROM at startup to ensure correct firmware version).

Anyway - currently it starts a few tasks, so you can apply the patch and start identifying stubs. Some of them are useful for debugmsg.gdb as well (e.g. DebugMsg, task_create). The current state is also enough for testing the boot process (to see whether ML is able to run code alongside the main Canon firmware, reserve memory for itself, start a task and so on). It won't display any GUI yet, but it shouldn't be hard to reach the Hello World stage without this functionality.

I am actually floored by how quickly you got this done. I get you know what you are doing, but damn you are committed for an open source project.

RIGHT, brown-nosing over.

Finding the stubs seems to be an accomplishable goal I can do, i found the relevant forum threads and I mostly get the asm command set now, at least typologically, so ill get stuck into that.I might use the 60D as a base reference for the stubs as it seems to be the most related hardware wise.

Just a question on starting a new platform definition in the ML source.Is there a base set of source for the platform that can be used that has a minimal feature/module set enabled?

Ive tried copying the 60D set, and stripping down to minimal components, but im getting feature define compile time failures such as CAM_COLORMATRIX1 and RAW_ZEBRA_ENABLE. I could go through one at a time and fix them, but it seems im working backwards.

Basically I want to start a 1300D platform definition which can really just execute the hello world example, which I believe is what you meant as well?That and its the only certain way to confirm the found stubs i believe?

basically, what I did when starting to port was taking a copy of another camera and rename it.For e.g. you take 60D or 600D for Digic IV.

Afterwards you rename it and do it step by step as you already guessed.First you grep for "CONFIG_60D" and then "60D" and then "60d" and you should find almost everything needed. In internals.h you undefine this:

(I know, they are not isolated very well, as we don't turn them off very often...)

You can also use the minimal target, but that one is really minimal (useful for a lower-level version of Hello World). It uses the platform-specific files (stubs, consts) from the platform directory, a single source file for experiments (minimal.c) and a tiny graphics library (font_direct.c) - besides the loader code in reboot.c. Therefore, it's a good playground environment that does not touch the larger codebase (and does not require a lot of stubs/consts to get started).

The digic6-dumper branch also makes use of the minimal target, but a different way (using a platform-specific minimal.c - because the current boot process has to be changed significantly for newer models). I hope it's not needed for 1300D.

Thats what ive been trying, but ive flushed my work and started fresh in case I royally stuffed something.

Basically ive copied to 60D definition, replaced all the specifics, undefined CONFIG_PROP_REQUEST_CHANGE as recommended, and added the 1300D (firmware 110) to the main Makefile and Makefile.platform.map

Other cameras have dummy definitions (those 0x123456), so anything that checks if the current GUI mode is GUIMODE_FOCUS_MODE will be false.

In general, if you have doubts about a constant, grep the source code to see how it's used. Some of them are used as memory locations where things are written - these need additional care, as the camera bricking does happen (should be recoverable in most cases, but it's best not to get there). This should help understanding why this happens - although the only 100% sure way to prevent bricking is... executing it only in QEMU.

Yes, it does (it's a side effect of my modification - one of the reasons I'm not going to commit it in this state). When setting the boot flag, MEM_WRITE_ROM writes to the first copy of the ROM (the one modelled as I/O), and the write is currently ignored.

As a workaround, try writing the bootflag in another copy of the ROM (there are a bunch of mirrored ones - any of them will update all the others). For example, .bootflags_addr = 0xFA000000 (not tested). What I've tested was changing MEM_WRITE_ROM to write at addr+ROM0_SIZE, but that's way too hackish.

Just so this isnt a sudden stop thread, taking a short hiatus because having 2 VM's running for build/testing and searching a 400mb+ file to identify stubs is making my laptop glow red.

Fully intend to resume work in ~2 weeks when I have access to my normal development machine (reason: working remote currently)

Thanks for the help (read: doing 99.99995% of the work) A1ex and Nikfreak. And thanks for the solid explainations. Only a few days in and this has already been my most positive experience with OSS projects to date.

Well, that was because the first assert was not something I'd expect new contributors to be able to figure out (as it was not present on any other model, and requires a very good understanding of the ROM layout - which I don't have yet). This doesn't usually happen with things already documented or mentioned elsewhere.

And I also happened to have a few days off

Edit: looks like the proper way to implement a ROM in QEMU is by using memory_region_init_rom_device. However, that one appears to handle only writes with callbacks. Go figure...

Thanks to your earlier information cstart's already found, but im confused from that point how to identify bzero32 and create_init_task.I get both should be being called from cstart, and indeed there are two function calls in the cstart function, but the addresses they reference appear to be outside the ROM space.Are these functions being called out of RAM instead of ROM? If so, how would one go about dumping RAM in order to identify the functions and hopefully correlate them to their original ROM positions? Or do we not bother and simply reference them in RAM as well?

Unfortunately from what I can gather from forum information, most of the stub locating others have done have been as a result of effectively using manual signature techniques, or at least similarities to other model ROM's and their stubs, but of course we dont have that luxury here.

You can get the RAM contents either with dd (after identifying what is copied where), or from either QEMU or GDB (they both have commands for dumping the RAM). Or, you can disassemble directly from GDB or from the QEMU monitor console.

You'll need a RAM_OFFSET in the stubs file, similar to DIGIC 5 models. It's explained in the tutorial for finding stubs.

Which definitely looks like the type of function you would want in RAM as its intended for a coproc (sic?) and hence would want to be accessible from said RAM as it may reference other local functions the coproc needs to execute/