Canon EOS 1300D / Rebel T6

[the12354]

Hi,
i'm a coder/immediate re who just bought a EOS 1300D and would like to port magic lantern to it.
I've read around the forum and the first step for porting is dumping the firmware. I've tried the portable rom dumper but unfortunately nothing happens(black screen, camera needs to be reset using the battery).
Another way i've seen is using specifically crafted .fir files.
What do i need to provide to get a .fir dumper for this camera from you?

[a1ex]

Try this one (not a ROM dumper, but should print some info on the screen):

http://www.magiclantern.fm/forum/index.php?topic=17714

What file did you run on 1300D? I don't remember publishing a ROM dumper for this camera yet...

[the12354]

Code: [Select]

CHDK CPU info for 0x0 ERROR
-----------------------
ID 0x41059461
Revision 0x1 1
Part 0x946 2374
ARM Arch 0x5 5
Variant 0x0 0
Implementor 0x41 65

Cache type 0x0F112112
Icache words/line 0x2 2 [8]
Icache absent 0x0 0
Icache assoc 0x2 2
Icache size 0x4 4 [8K]
Reserved0_2 0x0 0
Dcache words/line 0x2 2 [8]
Dcache absent 0x0 0
Dcache assoc 0x2 2
Dcache size 0x4 4 [8K]
Reserved1_2 0x0 0
Harvard/unified 0x1 1
Cache type 0x7 7
Reserved2_3 0x0 0
TCM type 0x000C00C0
Reserved0_2 0x0 0
ITCM absent 0x0 0
Reserved1_3 0x0 0
ITCM size 0x3 3 [4K]
Reserved2_4 0x0 0
DTCM absent 0x0 0
Reserved3_2 0x0 0
DTCM size 0x3 3 [4K]
Reserved4_10 0x0 0
Control 0x0005107D
Protect enable 0x1 1
Reserved0_1 0x0 0
Dcache enable 0x1 1
Reserved1_4 0xF 15
Big endian 0x0 0
Reserved2_4 0x0 0
Icache enable 0x1 1
Alt vector 0x0 0
Cache RRR 0x0 0
Disble loadTBIT 0x0 0
DTCM enable 0x1 1
DTCM mode 0x0 0
ITCM enable 0x1 1
ITCM mode 0x0 0
Reserved3_12 0x0 0
Protection Region 0 0x0000003F
Enable 0x1 1
Size 0x1F 31 [4G]
Undef0_7 0x0 0
Base 0x0 0 [0x00000000]
Protection Region 1 0x0000003D
Enable 0x1 1
Size 0x1E 30 [2G]
Undef0_7 0x0 0
Base 0x0 0 [0x00000000]
Protection Region 2 0x00000037
Enable 0x1 1
Size 0x1B 27 [256M]
Undef0_7 0x0 0
Base 0x0 0 [0x000000000]
Protection Region 3 0xC0000039
Enable 0x1 1
Size 0x1C 28 [512M]
Undef0_7 0x0 0
Base 0x60000 393216 [0xC0000000]
Protection Region 4 0xF8000031
Enable 0x1 1
Size 0x18 24 [32M]
Undef0_8 0x0 0
Base 0x7C000 507904 [0xF8000000]
Protection Region 5 0xFE000031
Enable 0x1 1
Size 0x18 24 [32M]
Undef0_7 0x0 0
Base 0x7F000 520192 [0xFE000000]
Protection Region 6 0x00000000
Enable 0x0 0
Size 0x0 0 [invalid]
Undef0_7 0x0 0
Base 0x0 0 [00000000]
Protection Region 7 0x00000000
Enable 0x0 0
Size 0x0 0 [invalid]
Undef0_7 0x0 0
Base 0x0 0 [00000000]
Region data perms 0x00333333
Region 0 0x3 3 [P:RW U:RW]
Region 1 0x3 3 [P:RW U:RW]
Region 2 0x3 3 [P:RW U:RW]
Region 3 0x3 3 [P:RW U:RW]
Region 4 0x3 3 [P:RW U:RW]
Region 5 0x3 3 [P:RW U:RW]
Region 6 0x0 0 [P:-- U:--]
Region 7 0x0 0 [P:-- U:--]
Region inst perms 0x00333333
Region 0 0x3 3 [P:RW U:RW]
Region 1 0x3 3 [P:RW U:RW]
Region 2 0x3 3 [P:RW U:RW]
Region 3 0x3 3 [P:RW U:RW]
Region 4 0x3 3 [P:RW U:RW]
Region 5 0x3 3 [P:RW U:RW]
Region 6 0x0 0 [P:-- U:--]
Region 7 0x0 0 [P:-- U:--]
DCache cfg 0x00000024
Region 0 0x0 0
Region 1 0x0 0
Region 2 0x1 1
Region 3 0x0 0
Region 4 0x0 0
Region 5 0x1 1
Region 6 0x0 0
Region 7 0x0 0
ICache cfg 0x00000024
Region 0 0x0 0
Region 1 0x0 0
Region 2 0x1 1
Region 3 0x0 0
Region 4 0x0 0
Region 5 0x1 1
Region 6 0x0 0
Region 7 0x0 0
Write buffer 0x00000024
Region 0 0x0 0
Region 1 0x0 0
Region 2 0x1 1
Region 3 0x0 0
Region 4 0x0 0
Region 5 0x1 1
Region 6 0x0 0
Region 7 0x0 0
DTCM cfg 0x40000006
Reserved0_1 0x0 0
Size 0x3 3 [4K]
Undef0_7 0x0 0
Base 0x20000 131072 [0x40000000]
ITCM cfg 0x00000006
Reserved0_1 0x0 0
Size 0x3 3 [4K]
Undef0_7 0x0 0
Base 0x0 0 [0x00000000]
Here are the images i took(with postprocessing for readability) for reference:
http://imgur.com/a/OIqck

I've used this one (http://www.magiclantern.fm/forum/index.php?topic=16534.0) but i guess it's only for cameras where ML is already installed?

[a1ex]

You mean, autoexec.bin? How did you manage to lock up the camera without enabling the boot flag first?!

Anyway, here's the portable ROM dumper: DUMP1300.FIR

If successful, please send me the ROM by PM.

The info looks fairly similar to digic 4; the two 32MB ROMs are a bit unusual. RAM seems to be 256M.

Your first task is to run your ROM under QEMU (same for anyone else interested). Without seeing the firmware, I expect:
- loading autoexec from SD card should work with little or no tweaking (it may lock up at some GPIO registers, easy to fix)
- the portable display test should also run with minimal effort
- if you run it under GDB, you should also see a few tasks starting
- if you are lucky, you might even see Canon GUI (but don't get your hopes too high on this one).

[the12354]

Thanks for the dumper.
Unfortunately it does not seem to dump anything. Nothing changed on the SD Card.
It looks like it freezes after saying "Dumping ROM0..." (i reset the camera after 1 hour).


This is the full log i get:

Code: [Select]

Magic Lantern Rescue
--------------------------
- Model ID: 0x0 ERROR
- Camera model: ???
- Firmware version: ??? / ???
- IMG naming: 100?????/????0000.JPG
- Artist: ???
- Copyright: ???
- Boot flags: FIR=0 BOOT=0 RAM=-1 UPD=-1
- Init SD... (101F64)
- Dumping ROM0...

[a1ex]

You may have better luck with a smaller card, or maybe even with a card formatted at a smaller capacity. For me, this tool works best on an old 256 MB card.

[the12354]

Thanks, resizing the sd card to 256MB worked.

[a1ex]

ROM layout is a little unusual:

- The two ROMs at F8000000 and FE000000 are identical, so it probably has a ROM chip at F8000000, mirrored as usual until FFFFFFFF (4 copies x 32MB). We call this one ROM1.
- There seems to be another 32MB ROM chip at F0000000 (ROM0).
- Bootloader appears to be at F8010000, but the first instruction jumps to FFFF0040. Code at F8010040 looks valid. The ARM946 can start from either 0 (unlikely, that's the RAM) or FFFF0000 (HIVECS configuration). However, the ROM dump after FFFF0000 is... empty!
- I've assumed there is some sort of mapping from FFFF0000 to F8010000. To run the ROM in QEMU, you will need to patch the dump like this:

Code: [Select]

dd if=ROM1.BIN of=BOOT.BIN bs=64k skip=1 count=1
dd if=BOOT.BIN of=ROM1.BIN bs=64k seek=511

After this, running in QEMU is more or less straightforward, with a small reverse engineering puzzle to solve.

Have fun!

[Rongronggg9]

256M SD Card, FAT format
It took 10min to dump.


But without other compatible files, I can't find any differences...
With 1100D files, there's still no difference...
(Maybe I've said something useless..)
_(:зゝ∠)_


I am a high school student from China, so...
There's something I can't understand very well.

How to patch the dump?

I've managed to search for it but I can't find anything useful.
Maybe I am too stupid...
(＞д＜)
(I apologize for not being word-perfect in English...)

[adamnock]

Right im resurrecting this only slightly cooled off thread because its right what I need

Dumped ROM - Success. Did it twice and compared, good dumps I assume as they were identical.
Patched ROM as per above instructions.

Compiled QEMU and added Machine Rego in eos.c for the 1300D.
HOWEVER. I dont actually have any clue what the register address in the source is supposed to be targeting. I set it to FF801000 which is noted above as being the bootloader position, and got some minor output suggesting some code was executed, but it stalled after a few shifts, so im thinking im in the wrong boot position. But honestly, I only have a small idea of what im doing here, just an honest interest in figuring it out.

Any suggestions from the almightly userbase?

Possible Progress?
I tried to figure out the offset from the ROM, and came up with 0xF8008000 based on the above patch to ROM1.
Lo an behold there was some execution and what looks like now idle output on the console. No picture though.

[EOS] loading 'ROM-1300D.BIN' to 0xF0000000-0xF1FFFFFF
[EOS] loading 'ROM-1300D.BIN' to 0xF8000000-0xF9FFFFFF
[] [0xC7C287C0] -> [0xC7C287C0] PC: 0xF80277A0
[] [0x00000000] -> [0xC7C287C4] PC: 0xF80277A0
[] [0xC7C287C0] -> [0xC7C287C0] PC: 0xF80277A0
[] [0x00000000] -> [0xC7C287C4] PC: 0xF80277A0
[] [0xCFC00FD8] -> [0xCFC00FD8] PC: 0xF80277A0
[] [0x00000000] -> [0xCFC00FDC] PC: 0xF80277A0
[] [0xCFC00FD8] -> [0xCFC00FD8] PC: 0xF80277A0
[] [0x00000000] -> [0xCFC00FDC] PC: 0xF80277A0
[] [0xCFC00FD8] -> [0xCFC00FD8] PC: 0xF80277A0
[] [0x00000000] -> [0xCFC00FDC] PC: 0xF80277A0
[] [0xCFC00FD8] -> [0xCFC00FD8] PC: 0xF80277A0
[] [0x00000000] -> [0xCFC00FDC] PC: 0xF80277A0
[] [0xCFC00FD8] -> [0xCFC00FD8] PC: 0xF80277A0
[] [0x00000000] -> [0xCFC00FDC] PC: 0xF80277A0
[] [0xCFC00FD8] -> [0xCFC00FD8] PC: 0xF80277A0
[] [0x00000000] -> [0xCFC00FDC] PC: 0xF80277A0
[] [0xCFC00FD8] -> [0xCFC00FD8] PC: 0xF80277A0
[] [0x00000000] -> [0xCFC00FDC] PC: 0xF80277A0
[] [0xCFC00FD8] -> [0xCFC00FD8] PC: 0xF8027800
[] [0x00000000] -> [0xCFC00FDC] PC: 0xF8027800
[] [0xC7B18BA0] -> [0xC7B18BA0] PC: 0xF80325D0
[] [0x00000000] -> [0xC7B18BA4] PC: 0xF80325D0
[] [0xC7B18BA0] -> [0xC7B18BA0] PC: 0xF80325D0
[] [0x00000000] -> [0xC7B18BA4] PC: 0xF80325D0
[] [0xC7B18BA0] -> [0xC7B18BA0] PC: 0xF80325D0
[] [0x00000000] -> [0xC7B18BA4] PC: 0xF80325D0
[] [0xC7B18BA0] -> [0xC7B18BA0] PC: 0xF80325D0
[] [0x00000000] -> [0xC7B18BA4] PC: 0xF80325D0
[] [0xC7B18BA0] -> [0xC7B18BA0] PC: 0xF80325D0
[] [0x00000000] -> [0xC7B18BA4] PC: 0xF80325D0
[] [0xCFAE6594] -> [0xCFAE6594] PC: 0xF80325D0
[] [0x00000000] -> [0xCFAE6598] PC: 0xF80325D0
[] [0xCFAE6594] -> [0xCFAE6594] PC: 0xF80325D0
[] [0x00000000] -> [0xCFAE6598] PC: 0xF80325D0
[] [0xCFAE6594] -> [0xCFAE6594] PC: 0xF80325D0
[] [0x00000000] -> [0xCFAE6598] PC: 0xF80325D0
[] [0xC7EAFD58] -> [0xC7EAFD58] PC: 0xF8032878
[] [0x00000000] -> [0xC7EAFD5C] PC: 0xF8032878
[] [0xC7EAFD58] -> [0xC7EAFD58] PC: 0xF8032878
[] [0x00000000] -> [0xC7EAFD5C] PC: 0xF8032878
[] [0xC7EAFD58] -> [0xC7EAFD58] PC: 0xF8032878
[] [0x00000000] -> [0xC7EAFD5C] PC: 0xF8032878
[] [0xC7EAFD58] -> [0xC7EAFD58] PC: 0xF8032878
[] [0x00000000] -> [0xC7EAFD5C] PC: 0xF8032878
[] [0xCFE7D4C0] -> [0xCFE7D4C0] PC: 0xF8032878
[] [0x00000000] -> [0xCFE7D4C4] PC: 0xF8032878
[] [0x00000040] -> [0xCCFFF340] PC: 0x07C008F4
[] [0x00000040] -> [0xCCFFF340] PC: 0x07C008F4
[] [0x00000040] -> [0xCCFFF340] PC: 0x07C008F4
[] [0x00000040] -> [0xCCFFF340] PC: 0x07C008F4
[] [0x00000040] -> [0xCCFFF340] PC: 0x07C008F4
[] [0x00000040] -> [0xCCFFF340] PC: 0x07C008F4

next step I guess is to attach gdb and try and figure out whats actually going on?
Also to figure out what the hell im doing.

EDIT2: OK So it helps if im running qemu using the patches in the current branch, not some old stuff. Whoops.

[adamnock]

OK, having checked out the correct branch for the current QEMU build, ive created a machine profile for the 1300D using values provided above for RAM size, ROM size and locations etc.

Starting to see some possible results:
FIXME: no MPU spells for 1300D.
FIXME: no MPU button codes for 1300D.
FFFF0AE0: MCR p15,0,Rd,cr6,cr0,0:  946_PRBS0 <- 0x3F       (00000000 - FFFFFFFF, 0x100000000)
FFFF0AE8: MCR p15,0,Rd,cr6,cr1,0:  946_PRBS1 <- 0x3D       (00000000 - 7FFFFFFF, 0x80000000)
FFFF0AF0: MCR p15,0,Rd,cr6,cr2,0:  946_PRBS2 <- 0x37       (00000000 - 0FFFFFFF, 0x10000000)
FFFF0AF8: MCR p15,0,Rd,cr6,cr3,0:  946_PRBS3 <- 0xC0000039 (C0000000 - DFFFFFFF, 0x20000000)
FFFF0B00: MCR p15,0,Rd,cr6,cr4,0:  946_PRBS4 <- 0xF8000031 (F8000000 - F9FFFFFF, 0x2000000)
FFFF0B08: MCR p15,0,Rd,cr6,cr5,0:  946_PRBS5 <- 0xFE000031 (FE000000 - FFFFFFFF, 0x2000000)
FFFF0B10: MCR p15,0,Rd,cr2,cr0,0: DCACHE_CFG <- 0x24       
FFFF0B18: MCR p15,0,Rd,cr3,cr0,0:       DACR <- 0x24       
FFFF0B1C: MCR p15,0,Rd,cr2,cr0,1: ICACHE_CFG <- 0x24       
FFFF0B20: MCR p15,0,Rd,cr5,cr0,0:    DATA_AP <- 0xFFF     
FFFF0B28: MCR p15,0,Rd,cr5,cr0,1:    INSN_AP <- 0xFFF     
FFFF0B2C: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0x2078
FFFF0B2C: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC000307D
FFFF00C4: MCR p15,0,Rd,cr9,cr1,1: XSCALE_UNLOCK_ICACHE <- 0x6        (00000000 - 00000FFF, 0x1000)
FFFF00C4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC000307D
FFFF00C4: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC004307D
FFFF00C4: MCR p15,0,Rd,cr9,cr1,0: XSCALE_LOCK_ICACHE_LINE <- 0x40000006 (40000000 - 40000FFF, 0x1000)
FFFF00C4: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC004307D
FFFF00C4: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005307D
FFFF0108: MRC p15,0,Rd,cr1,cr0,0:      SCTLR -> 0xC005307D
FFFF0108: MCR p15,0,Rd,cr1,cr0,0:      SCTLR <- 0xC005107D
System & Display Check & Adjustment program has started.

And then it hangs

Ill happily admit though that at this point im fairly lost, but ill do some reading to try and keep moving.

In the meantime if anyone can offer some suggestions, ive uploaded exec,int output and a function trace, plus the profile details to
https://drive.google.com/drive/folders/0B6Jkvpb0IV-zRkk0YWxLTXpuc0U?usp=sharing

[a1ex]

Looks good. Next step is to prevent the adjustment menu from coming up (and launch the main firmware instead).

You can also use -d io (or -d exec,int,io) to get some more info about what happens, and you may find it helpful following the code branches in IDA (e.g. press space in the disassembly tab). Additionally, -singlestep is useful for getting correct program counters in the io logs (otherwise, you'll often get the start of a small function, rather than the exact address where the MMIO access happens). You'll have to configure the emulator in a way that "forces" the boot code to pick the FROMUTILITY path, instead of the System adjustment menu.

The place where the code path should be changed is not the same place where it locks up (that's a bit tricky). However, all the functionality of the "guest" program (here, the firmware) can be changed from MMIO registers and/or triggering an interrupt (you only need the former method here).

MMIO registers and hardware interrupts are the only external interfaces of this CPU to other devices, as far as I could tell. MMIO registers cover GPIOs, interrupt controller(s?), DMA controllers, communication with other CPU cores, image processing modules, I2C, SPI, UART and so on. In our implementation, all of them are covered in the eos_handle_* functions (which looks a bit different from other QEMU code, as they were ported from another emulator, back in the old days).

An interrupt can be triggered whenever an external device does something interesting (here's an example).

[adamnock]

Thanks a1ex! Nice to meet you btw.

That makes sense. Ill have a look through the code at how such a boot shunt (term?) is achieved to skip Adjustment on another device so I can see what im looking at. Nitty gritty time.

[adamnock]

Right, well from looking at the io logging (thanks for the tip) there was only 2 unique GPIO reads occuring, suggesting I could do this by trial and error. The first caused no boot execution, going to assume that was the wrong one or wrong value

The second, which the GPIO handler has annotated as maybe being SD Detect for the 70D and 6D, proved more valuable.
Replacing the output of that overwrite with a 0 value skipped the SDAC and moved ahead. Whoopie!

The process seems to now move a lot further ahead, and positively is now halting with an Assert.

So! Its time for me to setup IDA i think.

Note: Ive uploaded new IO, EXEC and Calls outputs to the Google drive share
https://drive.google.com/drive/folders/0B6Jkvpb0IV-zRkk0YWxLTXpuc0U?usp=sharing

Plus updated the notes document to include the modified eos.c code.

[a1ex]

The second, which the GPIO handler has annotated as maybe being SD Detect for the 70D and 6D, proved more valuable.
Replacing the output of that overwrite with a 0 value skipped the SDAC and moved ahead. Whoopie!

Yep, that's the one.

Not sure what's causing the assert (didn't look much into it yet, other than noticing it depends on the output values given by sub_27C4, which is copied to RAM right before cstart - a process done on other DIGIC 5 and 6 cameras). The 1300D appears to have a few bits from the newer codebases backported on DIGIC 4.

Debugging in IDA may help:

Code: [Select]

./run_canon_fw.sh 1300D -d io -singlestep -s -S

followed by F9 in IDA.

Some useful functions:

Code: [Select]

FE0C0000 main firmware start
FE0C3A28 cstart
FE1279E8 init_task
FE0C1B60 AJ_massive_kernel_init

It also helps extracting the memory blocks copied to RAM and loading them in IDA at the copied location as additional binary files. The functions copied there will be executed from RAM.

Not sure how much it helps, but last night I've added other QEMU startup logs (from other camera models) here:
http://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-dm-spy/

[adamnock]

Thanks again!

Was there a good forum post or wiki article on setting up IDA? I havent had the opportunity to use it before, and so far ive not found anything on setup, or which version to use etc etc.

[adamnock]

Ah ok, the eval version of IDA Pro doesnt support GDB remote connections.
I get it now

[adamnock]

Not having much luck with IDA, very new to me, but learnings 90% of the fun.

On the flip side, I did try running the 1300D using the boot flag and got the portable display test and recovery screen. From above it seems thats expected and a good sign, so plus 1 I guess .

[a1ex]

Sounds like you are on the right track. The assert puzzle appears harder than I've expected - I've tried to debug it yesterday and here's what I found:

The tricky subroutine is called like this:

Code: [Select]

sub_27C4(0xF8000000, &out1, &out2, &out3);

0xF8000000 is the address used for boot flags. This suggests the 3 output values are probably read from there.

The next checks (before the assert) appear to accept the following values for out1-3: C2, 25, 39 or 20 BB 19 or 01 02 19 (hex). Each of these sequences is handled with a different subroutine: 2938 / 2B0C / 2CE4; they all allocate memory, fill in some round values and call FE2B486C (which is complicated).

Inside 27C4, there are a couple of functions that call others indirectly (BX R1); these are easy to get by running the debugger and finding the value of R1 (or PC after the call); understanding where this code takes these values from is a lot harder. Here's how to debug with GDB:

Code: [Select]

./run_canon_fw.sh 1300D -d exec,io -singlestep -s -S

then you need a debugmsg.gdb file:

Code: [Select]

source -v debug-logging.gdb

b *0xFE0C1B60
b *0x27C4

continue

then, in another terminal:

Code: [Select]

arm-none-eabi-gdb -x 1300D/debugmsg.gdb

then:

Code: [Select]

(gdb) layout asm
(gdb) layout regs
(gdb) si

If you want to jump over a function, gdb may complain ("Cannot find bounds of current function"); here's a workaround:

Code: [Select]

B+ │0x27ec  mov    r0, r6
   │0x27f0  bl     0x6e50
   │0x27f4  mov    r3, r8


Code: [Select]

(gdb) tbreak *0x27f4
(gdb) c

Now, our function returns 06 00 00 (instead of one of the accepted sequences). Where does that come from?!

[adamnock]

Brilliant, I actually understood most of that.
You wouldnt teach Comp-Sci would you?

Ill start looking around at that point. Maybe attack it the rock and hammer method and throw values at it and see what happens.

To horse!

[adamnock]

right, I see what you mean about 0xF8000000 changing unexpectedly.
And I figured out how to poke registers so thats another step down.

Eyes are crossing now, more tomorrow!
Thanks and have a good week.

[a1ex]

My hypothesis is that it might be trying to get some sort of manufacturer ID of the flash ROM chip.

See for example the K8P2815UQB datasheet (used in 7D, according to this page). Here's the I/O and ROM activity for the 7D, when trying to change the boot flag from the FROMUTILITY menu (Serial Console in QEMU window):

Code: [Select]

Is flg written(Y=ON(0xFFFFFFFF)/N=OFF(0x00000000))? :y
[FlashIF]  at 0x00102164:001021B8 [0xC0000000] -> 0x0       : ???
[FlashIF]  at 0x0010216C:001021B8 [0xC0000000] <- 0x1000000 : ???
[FlashIF]  at 0x00102178:001021B8 [0xC0000010] <- 0xD9C50000: 'Write enable' enabled
ROM(0xf8000aaa) = 0xaa (ignored)
ROM(0xf8000554) = 0x55 (ignored)
ROM(0xf8000aaa) = 0x80 (ignored)
ROM(0xf8000aaa) = 0xaa (ignored)
ROM(0xf8000554) = 0x55 (ignored)
ROM(0xf8000000) = 0x30 (ignored)
ROM(0xf8000000) => 0x0
ROM(0xf8000000) => 0x0
... (infinite loop)

This looks similar (but not identical) to the Block Erase sequence. Probably the chip is some related model (not exactly the one listed on the wiki page).

On 1300D, the following ROM accesses are made since "K404 READY":

Code: [Select]

K404 READY
ROM(0xf9000000) => 0x0
ROM(0xf8000000) => 0x0
ROM(0xf8000000) <= 0x6 (ignored)
ROM(0xf9000000) => 0x0
ROM(0xf8000000) => 0x0
ROM(0xf9000000) => 0x0
ROM(0xf8000000) => 0x0
ROM(0xf9000001) => 0x0
ROM(0xf8000001) => 0x0
ROM(0xf9000002) => 0x0
ROM(0xf8000002) => 0x0
ROM(0xf9000000) => 0x0
ROM(0xf8000000) => 0x0
ROM(0xf9000000) => 0x0
ROM(0xf8000000) => 0x0
ROM(0xf9000000) => 0x0
ROM(0xf8000000) => 0x0

Assert: File ./Startup/Startup.c Line 220

So, my best guess is that we should model this copy of the ROM as I/O memory and fake the data somehow.

Note: in QEMU, it's generally not possible to log every single memory access, unless that memory block is configured as I/O. However, memory implemented as I/O cannot contain executable code (so we have to choose one).

Side note: I'm currently looking at Panda (a fork of QEMU), which promises the ability to log any memory access, and a lot more useful analyses (look at plugins in their manual, for example).

https://github.com/moyix/panda/blob/master/docs/manual.md
http://moyix.blogspot.com/2013/09/announcing-panda-platform-for.html
https://gist.github.com/bridgeythegeek/d7a6c449287c6e32187be2639a7920bf

[adamnock]

So then assuming following your hypothesis, we should see a somewhat related compare between the K404 Ready and the Asset.

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.

Also I might try and find some high-res scans of the 1300D motherboard or similar to identify the exact Flash used.

[adamnock]

Hmm, all I can confirm from images (found some OKish on ebay) is:

CPU = Toshiba TMP19A43?DXBG (? appears to be an E. Wiki for 50D has same but with an F, trying to find datasheet to confirm significance of this part string letter)
RAM = 2x ELPIDA E1116A(5/8)E-P, 64MBx16 1GB DDR2-(667/800) (667 for a 5, 800 for a

Other IC's =  Princeton PT6590 LED Matrix Encoder (suppose driving the in-viewfinder data display)
Image Processor = DIGIC4+ (from documentation of course)

All the other IC's are either too small to read on the medium res photo, or covered by a shield, sadly the Flash appears it might be included, but that MIGHT be the LCD Processor given its placement.

Going to dig up the datasheet on the CPU to find out a bit more.

[adamnock]

E part for CPU doesnt exist, so its a

http://datasheet.octopart.com/TMP19A43FDXBG-Toshiba-datasheet-13724305.pdf

Same as the 70D (at least)