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?
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...
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?
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 (http://a1ex.magiclantern.fm/debug/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).
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:
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...
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.
Thanks, resizing the sd card to 256MB worked.
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:
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!
(http://ww4.sinaimg.cn/mw600/d46786adjw1fbqoy32a49j21kw0w0nfn.jpg)
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...)
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.
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
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 (https://www.magiclantern.fm/forum/index.php?topic=2882.0), back in the old days).
An interrupt can be triggered whenever an external device does something interesting (here's an example (http://www.magiclantern.fm/forum/index.php?topic=2388.msg183168#msg183168)).
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.
:)
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 :P
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.
Quote from: adamnock on April 22, 2017, 10:57:52 AM
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:
./run_canon_fw.sh 1300D -d io -singlestep -s -S
followed by F9 in IDA.
Some useful functions:
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/
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.
Ah ok, the eval version of IDA Pro doesnt support GDB remote connections.
I get it now
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 :).
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:
sub_27C4(0xF8000000, &out1, &out2, &out3);
0xF8000000 is the address used for boot flags (http://magiclantern.wikia.com/wiki/Bootflags). 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:
./run_canon_fw.sh 1300D -d exec,io -singlestep -s -S
then you need a debugmsg.gdb file:
source -v debug-logging.gdb
b *0xFE0C1B60
b *0x27C4
continue
then, in another terminal:
arm-none-eabi-gdb -x 1300D/debugmsg.gdb
then:
(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:
B+ │0x27ec mov r0, r6
│0x27f0 bl 0x6e50
│0x27f4 mov r3, r8
(gdb) tbreak *0x27f4
(gdb) c
Now, our function returns 06 00 00 (instead of one of the accepted sequences). Where does that come from?!
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!
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.
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 (http://www.bdtic.com/DataSheet/SAMSUNG/K8P2815UQB.pdf) datasheet (used in 7D, according to this page (http://magiclantern.wikia.com/wiki/Datasheets)). 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):
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":
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
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.
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 8)
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.
E part for CPU doesnt exist, so its a
http://datasheet.octopart.com/TMP19A43FDXBG-Toshiba-datasheet-13724305.pdf
Same as the 70D (at least)
Quote from: adamnock on April 24, 2017, 04:36:21 AM
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):
qemu-1300D.patch (http://a1ex.magiclantern.fm/bleeding-edge/1300D/qemu-1300D.patch)
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.
This is fun!
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:
#define CONFIG_PROP_REQUEST_CHANGE
and define CONFIG_HELLO_WORLD.
let me know if you get stuck or need help at finding a stub.
Besides nikfreak's advice, here are some useful tips:
Example for compiling without features: 60D-dm-spy.patch (https://bitbucket.org/hudson/magic-lantern/src/8b7912bd493317c9bd47f6ec659c05e661017dc4/platform/60D.111/60D-dm-spy.patch?fileviewer=file-view-default)
(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.
Hi nikfreak, thanks for the answer, and thanks a1ex again.
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
However with this minimal set, im seeing compile errors eg
../../src/focus.c:1024:33: error: 'GUIMODE_FOCUS_MODE' undeclared (first use in this function)
Whats confusing me is this isnt defined for the 60D either, but that compiles fine.
A walk through the source shows its typically defined in the platform consts
magiclantern@magiclantern-VirtualBox:~/magic-lantern$ grep -rnw './' -e "GUIMODE_FOCUS_MODE"
./platform/1100D.105/consts.h:56:#define GUIMODE_FOCUS_MODE 9
./platform/600D.102/consts.h:112: #define GUIMODE_FOCUS_MODE 9
./platform/550D.109/consts.h:121:#define GUIMODE_FOCUS_MODE 9
./platform/700D.114/consts.h:89: #define GUIMODE_FOCUS_MODE 0x123456
./platform/7D.203/consts.h:123:#define GUIMODE_FOCUS_MODE 9
./platform/6D.116/consts.h:128:#define GUIMODE_FOCUS_MODE 0x123456
./platform/5D3.123/consts.h:115:#define GUIMODE_FOCUS_MODE 0x123456
./platform/EOSM.202/consts.h:89:#define GUIMODE_FOCUS_MODE 0x123456
./platform/5D3.113/consts.h:100:#define GUIMODE_FOCUS_MODE 0x123456
./platform/unmaintained/40D.111/consts.h:71:#define GUIMODE_FOCUS_MODE 1234
./platform/unmaintained/5DC.111/consts.h:79:#define GUIMODE_FOCUS_MODE 12345
./platform/650D.104/consts.h:89: #define GUIMODE_FOCUS_MODE 0x123456
./platform/5D2.212/consts.h:87:#define GUIMODE_FOCUS_MODE 9
./platform/500D.111/consts.h:91:#define GUIMODE_FOCUS_MODE 0x27
./platform/50D.109/consts.h:117:#define GUIMODE_FOCUS_MODE 9
Am I missing something obvious here? Should I just define these constants simply for testing compile, or what?
Ill keep trying to figure out what im missing :)
AH, I get it.
Right, so there's some platform specific tweaks laying around in the primary project code.
OK, thats fine, ill start digging there.
Right, 60D has an exception exactly for this constant :D
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 (http://www.magiclantern.fm/forum/index.php?topic=19300.msg182570#msg182570) (should be recoverable in most cases, but it's best not to get there). This should help understanding why this happens (https://bitbucket.org/hudson/magic-lantern/pull-requests/825/prevent-canon-settings-from-being-saved/diff) - although the only 100% sure way to prevent bricking is... executing it only in QEMU.
right well I got ML built using a new platform definition, mostly bogus options of course, but where possible the right setup.
Copied autoexec.bin and 1300D_110.sym to the relevant QEMU 1300D folder, ran with the boot flag and...nothing.
Logout doesnt show autoexec.bin being loaded at all.
Its getting late and its a dawn ANZAC service tomorrow so im calling it a night.
Thanks for the help so far! Im understanding 'some' of what's being achieved, but taking notes. Interesting processes.
1300D_110.sym
that one needs to be 8.3. You need to rename and therefore shorten as well as redefine it in your platform dir's makefile.platform.default. Example from 1100D:
#Makefile.setup.platform for 1100D
# Definitions for version 105
ML_MODULES_SYM_NAME=t3_$(FW_VERSION).sym
...
So for 1300D you name it t6 (https://en.wikipedia.org/wiki/Canon_EOS_1300D)
Gotcha.
Ill give that a run in the morrow.
Ta :)
(supposed to be sleeping, going to be wrecked)
I wondered about the adapted code and how it was affecting bootflags as memory is being touched in the same area.
Im not sure why, its beyond my understanding of how Qemu is working, but the patch a1ex provided seems to be colliding with the bootflag setter
if (strcmp(s->model->name, "1300D") == 0)
{
switch (address)
{
case 0xF8000000:
case 0xF8000001:
case 0xF8000002:
{
/* fixme: a bit hackish */
unsigned int lr = CURRENT_CPU->env.regs[14];
if (size == 1 && lr == 0x1D4D4)
{
msg = "Flash model ID?";
const int model_id[] = { 0xC2, 0x25, 0x39 };
ret = model_id[address & 3];
break;
}
}
}
}
If I add a boot flag in there, setting 0xF8000000 to -1, we drop to the FROMUTILITY loader (on the plus side, the Firmware recovery GUI comes up perfectly on the Qemu display). But removing the touches of those two memory locations (0xF8000000 and 0xF8000001) brings us back to the Assert System.c issue.
Could there be a different value expected here for the boot flag? Or does the particular use case for the 1300D need adjustment in the way Qemu is setting that flag?
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.
Probably it's best to handle it in the ROM write handler.
Bam, shifting to an alternate copy region works a charm.
Thanks for that.
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.
Quote from: adamnock on April 25, 2017, 12:11:48 PM
Thanks for the help (read: doing 99.99995% of the work)
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 :D
Edit: looks like the proper way to implement a ROM in QEMU is by using memory_region_init_rom_device (https://github.com/qemu/qemu/blob/master/docs/memory.txt). However, that one appears to handle only writes with callbacks. Go figure...
Edit2: looks like memory_region_rom_device_set_romd (https://github.com/qemu/qemu/blob/master/include/exec/memory.h#L1006) might do exactly what we are looking for :D
Right so identifying the startup stubs.
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.
Some parts of the ROM are copied to RAM - see reply #14.
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.
These are helpful:
https://sourceware.org/gdb/onlinedocs/gdb/Machine-Code.html
https://en.wikibooks.org/wiki/QEMU/Monitor
Hi A1ex
Thanks for that.
I also found some detail in the CHDK wiki which covered about the same as the stubs tut but I think it clicked better.
I get what the job is now, thanks for the response :)
I had no luck with memory_region_rom_device_set_romd (the read callback is not called, only the write one), but I think I've found a cleaner workaround:
void * rom_ops_arg = (void *)((uintptr_t) s | rom_id);
memory_region_init_rom_device(rom, NULL, &rom_ops, rom_ops_arg, name, rom_size, &error_abort);
Then, just hardcode our magic numbers (model ID or whatever that is) in the first 3 bytes of ROM1. That appears to do the trick.
It doesn't log ROM reads though (which is something I wanted on all models, regardless of how the 1300D port will turn out).
Will update the patch later.
Alright so I created a watchpoint which waited for 0x29898 to change, which is where the first of the RAM referenced functions is located, considering you noted this was occuring before cstart.
This identified the following copy into that location:
f80c00a4: 34812004 strcc r2, [r1], #4
Following back further, we can identify r1 as being populated with a initial location point of....
f80c0094: e59f1044 ldr r1, [pc, #68] ; f80c00e0: (00001900)
Suggesting the RAM_OFFSET is 0x1900, which is the same as on the DIGIC-V, which helps corroborate my logic hopefully!
(not asking anything, just documenting my process so hopefully some interested person might catch a mistake and go 'WAIT YOU DOLT') :)
Wait thats not right....hmm, i think I know what I did wrong there
Right, so I understand now. Its not a case of identifying where in RAM the ROM portion is copied TO, is where it came FROM.
Also 0x1900 is the start point of the RAM copy of the ROM portion
Leading to the RAM OFFSET value being the location in ROM where the copy is done from, so that the STUB addres would be
the location in ROM, not RAM, which would be
RAM OFFSET address + (RAM function address - RAM start address)
So for the function at 0x29898, the STUB address would be
RAM_OFFSET + (0x29898 - 0x1900).
So now to figure out where its being copied from. That should be trivial I think.....
Right so assuming my previous was in any way right
f80c0090: e59f0044 ldr r0, [pc, #68] ; f80c00dc: (fea87718)
f80c0094: e59f1044 ldr r1, [pc, #68] ; f80c00e0: (00001900)
f80c0098: e59f3044 ldr r3, [pc, #68] ; f80c00e4: (0004f4ac)
loc_f80c009c:
f80c009c: e1510003 cmp r1, r3
f80c00a0: 34902004 ldrcc r2, [r0], #4
f80c00a4: 34812004 strcc r2, [r1], #4
f80c00a8: 3afffffb bcc loc_f80c009c
f80c00ac: e59f1034 ldr r1, [pc, #52] ; f80c00e8: (00084d7c)
f80c00a0: 34902004 ldrcc r2, [r0], #4
Is loading the relevant ROM data to be copied from the address at r0, with an offset of 4 into r2
f80c00a4: 34812004 strcc r2, [r1], #4
is then storing that ROM data into the address in r1, again with an offset of 4, which it gets from r2
f80c0094: e59f1044 ldr r1, [pc, #68] ; f80c00e0: (00001900)
Is the RAM start address, which leaves
f80c0090: e59f0044 ldr r0, [pc, #68] ; f80c00dc: (fea87718)
Which is the copy FROM location, which is pc + 68, which thanks to the helpful disassembly output, we know is 0xF80C00DC
Hence, the RAM_OFFSET is 0xF80C00DC
Note:
This could be additional verified by the fact that the code at F80C00DC is
f80c00dc: fea87718 mcr2 7, 5, r7, cr8, cr8, {0}
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/
Quote from: adamnock on April 26, 2017, 12:52:49 PM
[...] the code at F80C00DC is [...]
... is data, not code ;)
edit: committed the initial (https://bitbucket.org/hudson/magic-lantern/commits/cbf042bc9b403240c11d1a3516a10ae8278b569f) QEMU code (https://bitbucket.org/hudson/magic-lantern/commits/486a56848cc5e01a7b81787e54971c1be61b7c7b) for 1300D (https://bitbucket.org/hudson/magic-lantern/commits/f6951853578016789becca598345dbb6ed29c833) (no more need to monkey-patch the ROM with model ID) and also added an option that may help solving your puzzle (see these examples) (http://www.magiclantern.fm/forum/index.php?topic=2864.msg183838#msg183838)
(actually I want the memory tracing for other purposes, such as catching non-obvious, but potentially dangerous bugs; here it just happened to be helpful)
Alrighty then.
yes the memory trace seems like a very very handy feature.
Ill get started on it again this weekend!
Thanks for the heads up on the qemu updates :)
OK im a little confused....again
Ive got what i believe is most of the startup stubs identified, and compiled ML as such.
However, when booting with ML, which qemu is finding autoexec.bin off the SD card and booting it, i drop to the FROMUTILITY every time, without hitting any of the stub locations. Even if they were wrong, I believe I should see a jump to the location as ML tried to call those functions.
So, have I missed a step?
All I can see from searching around the forum is that the FROMUTILITY should be a option from a boot flag, but the output suggests 1 is the correct flag to boot autoexec.bin. Hence I can only assume its not loading?
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x3AFC0
Now jump to AUTOEXEC.BIN!!
************ FROMUTILITY MENU Ver 0.11 ************
[Type:404 Body:DC Rev:0.00 MID:0x88(Error)]
0.Factory Menu
1.Erase Sector Select
2.Erase Block Select
3.Erase Chip
4.Write from card
5.Write from DRAM
6.Firm flag 0xF8000000 0x00000000 ON
7.Boot flag 0xF8000004 0xFFFFFFFF ON
8.UpDate flag 0xF800000C 0xFFFFFFFF OFF
9.Create Boot Disk
A.Exec Program from SD
C.Connect card
D.SROM 4Byte Mode ON
G.Memory Dump
I.Write Data
J.Direct Jump
U.Firm update
Z.RCBIND.BIN update
>>
It's probably returning or jumping to some wrong address. An execution trace that covers only autoexec.bin (right after the "now jump to" message) should give more clues.
Wow, talk about perfect timing! I just purchased the Rebel T6, and I'm interested in magic lantern being ported for this. I have experience in programming and embedded electronics, however I never poked and prodded at an expensive DSLR before. Just came across this thread, so I figured I would say something. I can't afford to take my T6 apart right this second, so I may ask, what all could I possibly help with, if need be?
Hi Electrohead
Current priority is finding the relevant code stubs.
http://www.magiclantern.fm/forum/index.php?topic=12177.0
You can dump your camera's ROM without having to take it apart or anything horrible like that. Go back to the start of this post and look at A1ex's first couple of replies, they contain the details.
Then you want to check out and build the latest 'qemu' branch of the source, which contains the work A1ex has done on getting the 1300D emulatable etc.
Get yourself to the point where the ROM runs up past the Ready K404 debug output and you can get started with the above stub finding.
I had a priority project dumped on me at work, so ill be out of this for the next 8-10 days, but then ill get back in and keep working on it too :)
Hi folks,
I got the QEMU branch checked out, building okay (mostly) for 550D.109 (although I am getting errors about the 'dumper' directory not existing - need to investigate)
Just wondering what build target you are using for the 1300D testing ?
Thanks .. ken
Okay - making some progress now (I think).
I got a clean dev machine up and running, with qemu 2.9 and the latest arm toolchain - everything seems to be working with those, and with ML source (qemu-2.9 branch building successfully for 550D target)
.
I dumped my ROMs (1300D fw version 1.1.0) and I seem to be be able to run qemu with them - start up log below - but there is no ui visible in qemu, just random noise. I'm only using the default sd image - not installed anything on it (autoexec etc)
1) Is this (only noise) expected (at this stage)
2) Is there a minimum set of stubs to find to get *something* visible in qemu
3) Any info on the 'spells'
make: Entering directory '/home/osboxes/qemu/qemu-2.9.0'
make all-recursive
Making all in pixman
make[3]: Nothing to be done for 'all'.
Making all in demos
make[3]: Nothing to be done for 'all'.
Making all in test
make[3]: Nothing to be done for 'all'.
CHK version_gen.h
LEX convert-dtsv0-lexer.lex.c
BISON dtc-parser.tab.c
LEX dtc-lexer.lex.c
make: Leaving directory '/home/osboxes/qemu/qemu-2.9.0'
Lockdown read 0
Lockdown read 0
Lockdown read 1
Lockdown read 1
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
FIXME: no MPU button codes for 1300D.
Firm Jump RAM to ROM 0xFE0C0000
K404 READY
[DMA1] Copy [0xF8E60000] -> [0x402D4000], length [0x0026BBF8], flags [0x00030001]
[DMA1] OK
0: 1.280 [STARTUP]
K404 ICU Firmware Version 1.1.0 ( 4.4.6 )
[DMA1] Copy [0xF8D80000] -> [0x40584200], length [0x0007135C], flags [0x00030001]
[DMA1] OK
[DMA1] Copy [0xF8C29000] -> [0x40624300], length [0x00000F6C], flags [0x00030001]
[DMA1] OK
[DMA1] Copy [0xF8CE0000] -> [0x40625500], length [0x00016234], flags [0x00030001]
[DMA1] OK
[DMA1] Copy [0xF8C80000] -> [0x40645700], length [0x0001AEE8], flags [0x00030001]
[DMA1] OK
[MPU] receiving next message
[MPU] Request more data
[MPU] Request more data
[MPU] Received: 06 04 02 00 00 00 (recognized spell #1)
[MPU] Queueing spell #1.1
[MPU] Queueing spell #1.2
[MPU] Queueing spell #1.3
[MPU] Queueing spell #1.4
[MPU] Queueing spell #1.5
[MPU] Queueing spell #1.6
[MPU] Queueing spell #1.7
[MPU] Queueing spell #1.8
[MPU] Queueing spell #1.9
[MPU] Queueing spell #1.10
[MPU] Queueing spell #1.11
[MPU] Queueing spell #1.12
[MPU] Queueing spell #1.13
[MPU] Queueing spell #1.14
[MPU] Queueing spell #1.15
[MPU] Queueing spell #1.16
[MPU] Queueing spell #1.17
[MPU] Queueing spell #1.18
[MPU] Queueing spell #1.19
[MPU] Queueing spell #1.20
[MPU] Queueing spell #1.21
[MPU] Queueing spell #1.22
[MPU] Queueing spell #1.23
[MPU] Queueing spell #1.24
[MPU] Queueing spell #1.25
[MPU] Queueing spell #1.26
[MPU] Queueing spell #1.27
[MPU] Queueing spell #1.28
[MPU] Queueing spell #1.29
[MPU] Queueing spell #1.30
[MPU] Queueing spell #1.31
[MPU] Queueing spell #1.32
[MPU] Queueing spell #1.33
[MPU] Queueing spell #1.34
[MPU] Queueing spell #1.35
[MPU] Queueing spell #1.36
[MPU] Queueing spell #1.37
[MPU] Queueing spell #1.38
[MPU] Queueing spell #1.39
[MPU] Queueing spell #1.40
[MPU] Queueing spell #1.41
[MPU] Queueing spell #1.42
[MPU] Queueing spell #1.43
[MPU] Queueing spell #1.44
[MPU] Queueing spell #1.45
[MPU] Queueing spell #1.46
[MPU] Queueing spell #1.47
[MPU] Sending spell: 08 07 01 33 09 00 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 20 00 00
15: 22.272 [DISP] WARN BackLightOff
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 21 01 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 22 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 03 0c 01 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 03 0d 01 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 03 0e 01 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 08 06 01 23 00 01 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 08 06 01 24 00 00 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 08 06 01 25 00 01 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 2e 01 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 2c 02 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 03 20 04 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 3d 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 42 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 00 03 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 2c 2a 02 00 03 03 03 04 03 00 00 48 00 00 00 14 50 00 00 00 00 81 06 00 00 04 06 00 00 04 06 00 00 04 01 01 00 00 00 00 4d 4b 01 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 0c 0b 01 0a 00 01 00 00 00 00 00 00
[MPU] receiving next message
[MPU] Request more data
[MPU] Request more data
[MPU] Request more data
[MPU] Received: 08 06 00 00 02 00 00 00 (recognized spell #2)
[MPU] Queueing spell #2.1
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Request more data
[MPU] Sending spell: 06 05 01 37 00 00
[MPU] next message was started in SIO3
[MPU] Request more data
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Received: 0a 08 03 06 00 00 00 00 00 00 (recognized spell #4)
[MPU] Sending spell: 06 05 01 49 01 00
[MPU] next message was started in SIO3
[MPU] Request more data
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Received: 06 04 03 10 00 00 (recognized spell #5)
[MPU] Sending spell: 06 05 01 3e 00 00
[MPU] next message was started in SIO3
[MPU] Request more data
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Received: 06 05 03 07 ff 00 (recognized spell #6)
[MPU] Sending spell: 08 06 01 45 00 10 00 00
[MPU] receiving next message
[MPU] Request more data
[MPU] Request more data
[MPU] Received: 06 05 01 2e 01 00 (recognized spell #7)
[MPU] Queueing spell #7.1
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Request more data
[MPU] Sending spell: 06 05 01 48 01 00
[MPU] next message was started in SIO3
[MPU] Request more data
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Request more data
[RTC] !! RTC_TIME_CORRECT_CHANGE! 0x0 ---> 0xfd
[MPU] Sending spell: 06 05 01 4b 01 00
[MPU] next message was started in SIO3
[MPU] Received: 0a 08 03 0b 00 00 00 00 00 00 (recognized spell #8)
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Request more data
[MPU] Sending spell: 06 05 01 40 00 00
[MPU] next message was started in SIO3
[MPU] Request more data
[MPU] Received: 08 07 03 54 00 00 00 00 (unknown spell)
ASSERT : SystemIF::KerSem.c, Task = ShootCapture, Line 314
57: 40.448 [RSC] hMemoryQueue (0x660012) hStorageQueue (0x680014)
120: 45.056 [RTC] PROPAD_GetPropertyData : PROP_RTC 0xfd
121: 46.592 [RTC] ChangePropertyCBR 0x0, 0x0
122: 46.848 [RTC] RTC_Permit 0x0
133: 46.848 [SND] Seq LPC fin
150: 47.360 [ENG] [ENGIO](Addr:0x4fb40000, Data:0x 30000)
151: 47.360 [STARTUP] ERROR ASSERT : SystemIF::KerSem.c, Task = ShootCapture
152: 47.360 [STARTUP] ERROR ASSERT : Line 314
153: 47.360 [STARTUP] ERROR ASSERT : 0
154: 47.360 [STARTUP] ASSERT : Time 2000/1/1 0:0:0
155: 47.360 [STARTUP] startupErrorRequestChangeCBR (0x1d)
156: 47.360 [STARTUP] startupErrorRequestChangeCBR : ErrorSend (101, ABORT)
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Request more data
[MPU] Sending spell: 06 05 01 41 00 00
[MPU] next message was started in SIO3
[MPU] Request more data
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Request more data
169: 48.[MPU] Sending spell: 06 05 01 3f 00 00
[MPU] next message was started in SIO3
[MPU] Received: 08 06 03 03 65 01 00 00 (unknown spell)
384 [TERMINATE] SHUTDOWN init comp
171: 48.640 [TERMINATE] Abort init comp
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Request more data
[MPU] Sending spell: 1a 18 01 4e 00 00 00 00 00 00 00 00 00 00 00 19 00 00 00 0c 00 00 00 00 00 00
[MPU] next message was started in SIO3
[MPU] Received: 06 05 03 19 01 00 (recognized spell #22)
[MPU] Request more data
[MPU] Request more data
[MPU] Request more data
193: 50.176 [MC] PROP_GUI_STATE 0
[MPU] Received: 06 05 01 56 00 00 (recognized spell #9)
198: 50.688 [MC] JobState 0
202: 50.944 [MC] PROP_LCD_OFFON_BUTTON : 0
204: 51.200 [MC] PROP_VARIANGLE_GUICTRL : Enable
[MPU] Request more data
[MPU] Request more data
207: 51.712 [MC] regist master CardCover
[MPU] Request more data
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Received: 06 05 04 0e 01 00 (recognized spell #10)
[MPU] Sending spell: 06 05 01 48 01 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 53 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 4a 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 50 03 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 08 06 01 51 70 48 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 52 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 54 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 03 37 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 0e 0c 02 05 00 00 01 01 00 00 00 00 00 00
[MPU] spell finished
[MPU] Requesting next spell
222: 60.672 [PRP] NO AnalyzeMpuReceiveData 0x2 0x5
[MPU] Sending spell: 0a 08 02 06 04 00 00 00 00 00
223: 60.928 [PRP] ERROR EventDispatch : Current = 0, dwEventID = 10, dwParam = 0x66fbe0
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 0c 0a 02 07 06 00 00 00 00 00 00 00
[MPU] spell finished
[MPU] Requesting next spell
224: 63.488 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80010006 L:806
225: 63.488 [PRP] PropertyList:4 Current:6
[MPU] Sending spell: 0c 0a 02 08 06 01 00 00 00 00 00 00
[MPU] spell finished
[MPU] Requesting next spell
226: 65.024 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80010007 L:806
227: 65.024 [PRP] PropertyList:4 Current:6
[MPU] Sending spell: 0a 08 03 2f 00 00 00 00 00 00
[MPU] spell finished
[MPU] Requesting next spell
228: 0.768 [RTC] ChangePropertyCBR 0x0, 0x0
229: 0.768 [RTC] RTC_Permit 0x0
[MPU] Sending spell: 06 05 03 05 02 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 1e 1c 03 30 65 65 50 50 53 53 53 53 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 30 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 0e 0c 03 2e 00 00 83 ad 00 00 db 71 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 03 35 01 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 1c 1b 03 1d 4a 00 00 00 00 00 00 4c 50 2d 45 36 00 00 00 00 00 01 00 ae 7e 3b 61 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 04 03 36 00 00
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 08 07 01 55 00 02 01 01
[MPU] spell finished
[MPU] Requesting next spell
[MPU] Sending spell: 06 05 01 2e 01 00
[MPU] receiving next message
[MPU] Request more data
[MPU] Request more data
[MPU] spell finished
[MPU] spells finished
[MPU] Request more data
[MPU] Received: 08 06 00 00 01 55 00 00 (recognized spell #3)
Yes, that's the current state.
The GUI will only show up after being able to log the MPU communication from a real camera. I've tried to guess it from another model, but this time I wasn't as lucky as with 1100D and 1200D (which happened to be very similar to 60D).
For info on the 'spells', see mpu.c (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu.c?fileviewer=file-view-default) (first comments) and the MPU communication (http://www.magiclantern.fm/forum/index.php?topic=17596.0) topic for the few details we know about them.
However, even without GUI, the emulation should let us cross-check the startup process (e.g. allocating memory for our own code, starting a user task alongside Canon firmware). See the logs from other models (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-boot-check/) (formatting is a bit broken, just noticed).
For minimal set of stubs - try compiling the minimal hello world (from the minimal directory) and find the ones required there. It won't show anything graphical in QEMU at this stage, unless you fake the bitmap display address somehow. However, that should be enough to validate the initial set of stubs (e.g. seeing both ML and Canon's tasks running on the console, and checking whether the memory is reserved correctly for our binary). You will need my assistance to run this binary on the camera at this stage (once you are ready to do that, get in touch with me on IRC).
The next step would be the full-fledged hello world (the one nikfreak was talking about) - which uses the regular ML codebase, rather than a minimal target. Once that one works, we can enable the boot flag and you'll be able to run your own code on the camera (autoexec.bin) without requiring my assistance. After that, the porting process will be more or less straightforward (enabling features, checking what works, what not and so on).
Quote from: a1ex on May 14, 2017, 01:03:14 AM
For info on the 'spells', see mpu.c (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/mpu.c?fileviewer=file-view-default) (first comments) and the MPU communication (http://www.magiclantern.fm/forum/index.php?topic=17596.0) topic for the few details we know about them.
Thanks I'll spend some time looking at this, see if I can make sense of any of it...
Quote from: a1ex on May 14, 2017, 01:03:14 AM
However, even without GUI, the emulation should let us cross-check the startup process (e.g. allocating memory for our own code, starting a user task alongside Canon firmware). See the logs from other models (https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-boot-check/) (formatting is a bit broken, just noticed).
I seem to be getting similar output in the startup, so I'm taking that as a positive... :-)
Seems to find the FW version, and a bunch of spells, then goes into some kind of loop...
I'm a bit confused as to how/where I'd add bits to get more info in the output - e.g. Available buttons etc... ??
Quote from: a1ex on May 14, 2017, 01:03:14 AM
For minimal set of stubs - try compiling the minimal hello world (from the minimal directory) and find the ones required there.
Struggling here - not seeing a 'hello world' in the minimal directory ? Can anyone elaborate on what I should be looking for here ?
I'd like to get this working as the next step - just as a small victory more than anything else...
Thanks again for the assistance .. Ken
Quote from: kennetrunner on May 14, 2017, 05:34:41 PM
I'm a bit confused as to how/where I'd add bits to get more info in the output - e.g. Available buttons etc... ??
The install script has some examples to get started; the QEMU and GDB manuals are also helpful.
The forum and the old wiki also have a lot of useful stuff, if you have the patience to browse them.
Quote from: kennetrunner on May 14, 2017, 05:34:41 PM
Struggling here - not seeing a 'hello world' in the minimal directory ?
cd minimal/60D.111
cat Makefile
make
locate minimal.c
cd ../..
grep -nri "hello, world" .
;)
Quote from: a1ex on May 14, 2017, 01:03:14 AM
For minimal set of stubs - try compiling the minimal hello world (from the minimal directory) and find the ones required there. It won't show anything graphical in QEMU at this stage, unless you fake the bitmap display address somehow. However, that should be enough to validate the initial set of stubs (e.g. seeing both ML and Canon's tasks running on the console, and checking whether the memory is reserved correctly for our binary).
*THINK* I have all the startup, file i/o and gui stubs located now.
I have a compiling minimal hello world for the 1300D (yay)...
I mounted the SD & CF (using mount.sh) and copied the resulting autoexec.bin and magiclantern.bin to both (SD and CF) and then ran it under QEMU, but no change to running with just the ROMs...
I think I need to work out how to get the SD bootable ? and maybe some of the hijacking stuff working ?
I'm a bit confused around the 'hijacking' code and all the defines that go along with it - not found any of those locations yet...
The SD image that comes with qemu is already bootable. To load autoexec.bin, use 1300D,firmware="boot=1" on the command line - this will enable the boot flag by patching the ROM image.
The hijack stubs are essential - they are used to reserve memory for our code from DryOS (so Canon code won't overwrite our application). Some of them were found earlier in this thread. Some tips: http://magiclantern.wikia.com/wiki/5d-hack
@kennetrunner
Totally off topic but noticed your avatar:
(http://www.magiclantern.fm/forum/index.php?action=dlattach;attach=988;type=avatar)
I work at DreamWorks Animation part-time so when I open this topic it looks like I'm actually working. ;D
Back on topic, hope my tips have been helpful for finding some of those stubs. I've gotten through a few simple firmware updates but nothing as ambitious as porting a new camera. Keep up the good work.
Yes, your tips have been very helpful @dfort - thanks - and thanks to @a1ex for all the pointers too...
Having trouble debugging code under qemu when I have firmware="boot=1" set...
I can see the autoexec.bin file being loaded and then we jump to it, but my -singlestep is never honoured - it just runs right through looping on PrefetchAbort 0005F158 lines.
I'm not expecting things to work correctly (fully) yet (as I don't have all the HIJACK bits fathomed out), but I wanted to be able to single step through it to check I am making 'progress'
I'm using this command line
./run_canon_fw.sh 1300D,firmware="boot=1" -singlestep -s -S & ~/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gdb -x 1300D/debugmsg.gdb
... am I missing something ?
Thx .. Ken
-singlestep does not produce visible results by itself - it affects the way QEMU translate the guest code (that is, a TranslationBlock will contain only one guest instruction). The program will still run just like before, maybe with a minor speed penalty.
The speed penalty is minor because TranslationBlock's are chained (linked), so an execution "step" will include more guest instructions. To prevent this chaining, you can also pass "-d nochain"; this mix of flags does have a noticeable speed penalty, but it's very helpful when writing analysis code on top of QEMU.
If you are trying to print all the instructions, as they are executed, try:
./run_canon_fw.sh 1300D,firmware="boot=1" -singlestep -d nochain,exec [...]
If you are OK with printing each instruction as it's translated (that is, only the first time the emulator encounters it), you get a massive speed boost by omitting nochain.
If you want to run it step by step, you can do so with GDB commands. You can place a breakpoint where autoexec.bin loads (0x800000) and run it step by step from there. It's very slow that way - I prefer collecting larger logs.
You can also toggle logging options from the QEMU monitor console (e.g. during a breakpoint set in gdb), but it's a bit of a hassle. Can probably be scripted (e.g. start logging with options X, Y, Z once the PC register reached address Q). If I need such triggers, I just hardcode them somewhere in the TB exec hook (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/eos/dbi/logging.c?fileviewer=file-view-default#logging.c-270); for example:
static void tb_exec_cb(void *opaque, CPUState *cpu, TranslationBlock *tb)
{
if (tb->pc == 0x800000) {
qemu_loglevel |= CPU_LOG_EXEC | EOS_LOG_IO;
}
}
PrefetchAbort sounds like the code likely jumped to some invalid memory address.
Got it, I didn't know that autoexec was loaded in a 0x800000 - I've got it singlestepping and hitting breakpoints in the autoexec code now...
Is there any posts on the details of cstart, bzero32 etc - or high level flow of the ROM startup ?
Looks like a bunch of copying to RAM locations... and something weird with populating the stack ?
Any details here might help me with finding the stubs a bit quicker...
Thanks .. KJ
So, a bit more on this...
Single stepped through a bunch of startup sequences for both 60D and 1300D - painfully slow but very useful in order to understand what is going on, and get a feel for the flow...
I'll write this up for a post later...
Anyway I can see a bunch of ROM sections get written to RAM, looks like jump tables in places, and a bunch of RAM gets zero'd out.
I'm interested in the 0x1900 location at the moment - I can see the HIJACK_TASK_ADDR is around here on the 60D (0x1a20 to be exact), so I'm wondering if this is a table of tasks / interrupt vectors or something ?
I'm struggling to find the address this would be for the 1300D - I've found all the other HIJACK values, so this is the last one I need.
Is 0x1A20 the top, or bottom, of the task stack ? How would I find the size ?
If anyone can elaborate in this area that would be great...
.. KJ
Okay - just some updates on the progress I've made so far...
- Compiled 'minimal' for 1300D (no errors)
- Running 'minimal' for 1300D under qemu (starts correctly, but later fails with continual looping PrefetchAbort errors)
- Followed the 'minimal' code through qemu:
- all seems okay until it branches off to reloc_entry() (which is where the PrefetchErrors come in)
- *think* I have most of the HIJACK addresses, but I may have one, some or all of the wrong (resulting in the Prefetch errors)
Not finding an easy way to spit out debug messages when debugging it running under qemu.
I've resorted to inserting 'recognizable' assembler commands (that do nothing) at various points - this is a PITA !!
Any hints on a better stratgey would be well received :-)
... More investigation required :-)
.. KJ
Seems you are putting some efforts in.
Maybe I missed it but do you already have a public fork available for those who want to have a look or try to help?
Quotedo you already have a public fork available for those who want to have a look or try to help?
@nikfreak not yet - but probably made enough progress to warrant one now...
The problem I think I've having is this (in minimal.c) :
// We enter after the signature, avoiding the
// relocation jump that is at the head of the data
thunk reloc_entry = (thunk)( RELOCADDR + 0xC );
RELOCADDR looks like this (obviously the addresses are in the relocated segment, rather than the 0xfeXXXXXX range:
fe010000: e59ff018 ldr pc, [pc, #24] ; fe010020: (ffff0040)
fe010004: e59ff018 ldr pc, [pc, #24] ; fe010024: (ffff06d0)
fe010008: e59ff018 ldr pc, [pc, #24] ; fe010028: (ffff06fc)
fe01000c: e59ff018 ldr pc, [pc, #24] ; fe01002c: (ffff0728)
fe010010: e59ff018 ldr pc, [pc, #24] ; fe010030: (ffff0754)
fe010014: e1a00000 nop ; (mov r0, r0)
fe010018: e59ff018 ldr pc, [pc, #24] ; fe010038: (ffff0780)
fe01001c: e59ff018 ldr pc, [pc, #24] ; fe01003c: (ffff0798)
fe010020: ffff0040 ; <UNDEFINED> instruction: 0xffff0040
fe010024: ffff06d0 ; <UNDEFINED> instruction: 0xffff06d0
fe010028: ffff06fc ; <UNDEFINED> instruction: 0xffff06fc
fe01002c: ffff0728 ; <UNDEFINED> instruction: 0xffff0728
fe010030: ffff0754 ; <UNDEFINED> instruction: 0xffff0754
fe010034: 00000000 andeq r0, r0, r0
fe010038: ffff0780 ; <UNDEFINED> instruction: 0xffff0780
fe01003c: ffff0798 ; <UNDEFINED> instruction: 0xffff0798
so we're jumping to 0xffff0728 - which is the subroutine for 'PrefetchAbort' errors...
Do I have the wrong address ? or ... if I remove the + 0x0C, it jumps to 0xffff0040 which just does the startup stuff again...
Question: Where is it we are trying to locate to ?
Thanks .. KJ
The reloc_entry() problem was a dumb mistake - I was using 0xFE010000 for the firmware start instead of 0xFE0C0000...
Anyway, after a
few lot of pointers from @a1ex I think I have the basis of a working (minimal) port.
(http://preview.ibb.co/gxhTdF/1300d_ml.png) (http://ibb.co/j2tZJF)
Ultimately it still crashes, but that is 'expected' as the qemu EOS stuff does not support 'reads'.
QuoteThis is not the end, it is not even the beginning of the end, but it might be the end of the beginning
Now for more stub hunting...
Cool.
Sent from my iPhone using Tapatalk
A summary of the recent IRC discussions.
Quote
Not finding an easy way to spit out debug messages when debugging it running under qemu.
To print debug info from ML to the QEMU console, there is qprintf (in qemu-utils.c). I'd like to turn this into a "standard" debugging API, making it available anywhere in the source code (so it won't get compiled in the regular binary, but activated with CONFIG_QEMU=y). Halfway done on the "qemu" branch.
To control QEMU's verbosity, try running with "-d help" (there are many options). Note: most of these are on QEMU 2.5.0 (qemu branch in our tree). They are not ported to 2.9.0, where not all the basics are working properly yet.
Quote from: kennetrunner on May 19, 2017, 06:50:35 PM
Question: Where is it we are trying to locate to ?
RELOCADDR is in RAM (our modified copy of Canon's startup code). On 1300D, main firmware starts at FE0C0000, not FE010000, so we'll relocate the startup code from there, until being able to replace their init_task with our version. Once there, we can launch our own task(s) alongside Canon's.
QuoteI can see the HIJACK_TASK_ADDR is around here on the 60D (0x1a20 to be exact), so I'm wondering if this is a table of tasks / interrupt vectors or something ?
HIJACK_TASK_ADDR is probably the same as CURRENT_TASK in GDB and current_task in stubs.S (pointer to the current task structure - see tasks.h).
In 1300D/debugmsg.gdb:
macro define CURRENT_TASK 0x31170
macro define CURRENT_ISR (*(int*)0x31174 ? (*(int*)0x640) >> 2 : 0)
Also, to see tasks starting:
# this is valid on all firmware versions
b *0x38FC
task_create_log
# this one is for firmware 1.0.1
b *0xFE11D6B4
DebugMsg_log
This debugmsg.gdb is committed on the "qemu" branch, but I've only tested on firmware 1.0.1 (only noticed there's a newer firmware available after committing).
Quotehello world
23:22 < KennetRunner> or is it at a stage where I run hello world on my camera ?
23:24 < alexML> well, you can override the image buffer address before Canon GUI initializes the display (so ML code has
something to draw on)
23:24 < alexML> ML gets the buffer from bmp_vram_info[1].vram2 (where bmp_vram_info is a stub)
23:25 < alexML> rather than waiting for this to get valid (nonzero), just set it to something outside the normal RAM range
(e.g. 0x50000000 should be fine) and set QEMU to display from the same address
23:26 < alexML> this should give a hello world from the minimal platform, before getting the GUI working on the vanilla
firmware
23:26 < KennetRunner> I'll have a bash at that then...
23:27 < alexML> in qemu, look at s->disp.bmp_vram
I've also set up a job on the build server for QEMU 1300D tests, where you can find some startup logs with various levels of detail (firmware 1.0.1 for now):
http://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-1300D/
Got some time to look at this further now...
However, not sure what the (best) next step is ?
- just crack on with the stub hunting
- hack around the qemu eos stuff to let it return 'sensible/default' values reads - and try and get further in the standard ROM emulation
- pull together my own 'minimal' version of ML
- compile ML (no modules) and troubleshoot that running under qemu
Any thoughts ?
I have some progress on 1300D emulation (will publish soon), but still no GUI. We might have to get the MPU conversation from a real camera for that (and the path of least resistance requires booting ML first).
Probably the best way to proceed would be to try a minimal hello world first (to validate the startup process), and then do the same with regular ML.
Feel free to merge the qemu branch in your 1300D fork, as it has some useful tools for debugging the boot process, and I'd like to include it in the mainline soon. For example, you can now simply call qprint/qprintn/qprintf whenever you want to print something to emulator console (example (https://bitbucket.org/hudson/magic-lantern/commits/6c2908d922f75fae9ac8d9bfa30105e7d0fa010d?at=qemu) and results (http://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-boot-check/QEMU_boot_check_logs/)). These calls are only compiled with CONFIG_QEMU=y, so regular builds will not include these messages. The first two are available very early in the boot process; the third requires Canon's vsnprinf, which appears to require some initialization.
Also take look at other recent ports (EOS M2, 1200D, 100D, 70D) for a general idea.
Hi, I've just purchased my first canon(1300D) and found this forum. Thanks for all the work you are all doing, I have not much in the way of skills to help only do a bit of programing in c+ for arduino. But happy to help if I can. I don't know if this is possible but it would be great to be able to activate the wifi tethering to windows/laptop which is blocked.
Cheers
Makky
Quote from: Makky on June 24, 2017, 03:55:13 PM
Hi, I've just purchased my first canon(1300D) and found this forum. Thanks for all the work you are all doing, I have not much in the way of skills to help only do a bit of programing in c+ for arduino. But happy to help if I can. I don't know if this is possible but it would be great to be able to activate the wifi tethering to windows/laptop which is blocked.
Cheers
Makky
I'm in a similar boat; I bought a T6/1300D a few months ago, and noticed that efforts are ongoing to get MagicLantern working on it.
I have some C experience, so shouldn't be completely helpless, but I'm not at all sure what is useful to try to do. Perhaps the best to say is "watching with interest".
Minor progress with emulation:
- SD also works in main firmware, not just bootloader
- found the HDMI status GPIO (but didn't help much, other than cleaning the debug messages)
- patched JPCORE to avoid an assertion
Here's how I've found what to patch for the assert:
b *0x3CBC
assert_log
./run_canon_fw.sh 1300D,firmware="boot=0" -d callstack -s -S & arm-none-eabi-gdb -x 1300D/debugmsg.gdb
...
Current stack: [158398-157398] sp=158238 at [ShootCapture:3cbc:3320]
0xFE2BE514(796b3c &"StageClass", fe2be514, 19980218, 19980218) at [ShootCapture:41fc:158388] (pc:sp)
0xFE0CAAC4(796a70 &"ShootCapture", 0, 0, 0) at [ShootCapture:fe2be570:158360] (pc:sp)
0xFE2BE970(796ab8 &"StateObject", 796a70 &"ShootCapture", 0, 0) at [ShootCapture:fe0caaf0:158348] (pc:sp)
0xFE2BE9A8(796ab8 &"StateObject", 796a70 &"ShootCapture", 0, 0) at [ShootCapture:fe2be9a0:158338] (pc:sp)
0xFE12DB28(796a70 &"ShootCapture", 0, 0, fe12db28) at [ShootCapture:fe2bea28:158318] (pc:sp)
0xFE3ABD84(4fb1c080, 80000, 1, 25335c) at [ShootCapture:fe12db84:1582f0] (pc:sp)
0xFE539194(0, 142240, 141dfc, 31170) at [ShootCapture:fe3abdf0:1582a8] (pc:sp)
0xFE2A0164(40797480, 4079bd60, 792e34, 25) at [ShootCapture:fe5391b4:158290] (pc:sp)
0xFE2A16C8(0, 80000013, 4f550, 40000000) at [ShootCapture:fe2a01e4:158280] (pc:sp)
0xFE2A0088(7, 142240, 141dfc, 31170) at [ShootCapture:fe2a16ec:158270] (pc:sp)
0xFE4244FC(fe2a02c0 "JPEGICError", 0, 141dfc, 31170) at [ShootCapture:fe2a00d4:158260] (pc:sp)
0x3270(0, 0, 141dfc, 31170) at [ShootCapture:fe424510:158250] (pc:sp)
0x3CBC(3340, 332c "SystemIF::KerSem.c", 13a, 31170) at [ShootCapture:331c:158238] (pc:sp)
[ShootCapture:0000331c ] [ASSERT] 0 at SystemIF::KerSem.c:314, 3320
# patch JPCORE (assert)
set *(int*)0xFE4244FC = 0xe12fff1e
With this, the emulation moved forward, but still no GUI.
What's missing:
[ Startup:fe0d4054 ] (00:03) [SEQ] NotifyComplete (Cur = 1, 0x20000002, Flag = 0x20000000)
[ PowerMgr:fe0d4054 ] (00:03) [SEQ] NotifyComplete (Cur = 1, 0x2, Flag = 0x2)
[ FileMgr:fe0d4054 ] (00:03) [SEQ] NotifyComplete (Cur = 2, 0x10, Flag = 0x10)
[ Startup:fe0d4054 ] (00:03) [SEQ] NotifyComplete (Cur = 3, 0xe0110, Flag = 0x40000)
[ Startup:fe0d4054 ] (00:03) [SEQ] NotifyComplete (Cur = 3, 0xa0110, Flag = 0x80000)
[ Startup:fe0d4054 ] (00:03) [SEQ] NotifyComplete (Cur = 3, 0x20110, Flag = 0x100)
[ FileMgr:fe0d4054 ] (00:03) [SEQ] NotifyComplete (Cur = 3, 0x20010, Flag = 0x10)
Notice the pattern? The startup code expects a bunch of things to complete, but it doesn't really care about their order. There are a bunch of binary flags that get cleared whenever some component finishes its initialization. When all these flags are reset, the startup code moves on to the next stage. Therefore, to push the emulation even further (and hopefully get the GUI), one needs to:
1) find out who calls NotifyComplete(Flag = 0x20000) - easy
2) understand why it doesn't get called - hard
3) adjust the emulation so it gets called - easy after solving 2.
The above is not required for porting ML; you already have everything you need to print Hello World. It just makes things a bit easier.
Just stumbled upon this link. I have a 1300D myself and wanted to thank you guys for all the efforts being put into the ML build for 1300D. I have had some coding experience too in C/C++/Java/JavaScript etc. Let me know if I can help in any way.
Quote from: prvashisht on July 17, 2017, 05:06:50 PMLet me know if I can help in any way.
Of course. However, I'm afraid you'll have to... well... read the previous posts.
In particular, go to http://builds.magiclantern.fm/ and scroll to "Your camera is not listed?"
If you are waiting for me to port ML, it might not be the best choice. I'm providing tools (http://www.magiclantern.fm/forum/index.php?topic=2864), walkthroughs (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185103#msg185103), tutorials (http://www.magiclantern.fm/forum/index.php?topic=12177.0), advice and so on, other community members did their part (https://www.magiclantern.fm/forum/index.php?board=25.0) (in particular, this tutorial (https://www.magiclantern.fm/forum/index.php?topic=19417.0) is very helpful), but it's up to somebody who owns the camera to go through all this and complete the port.
I expect this to be one of the easiest cameras for porting ML (it's DIGIC 4, but has some things borrowed from both D5 and D6). 1200D and EOSM2 are marginally easier, but that's just because the emulator is able to display the GUI.
Ive put off coming back for too long (honestly I got quite lost but im still going to try and muddle my way through this).
a1ex / kennetrunner
Was there a branch of the project which included the QEMU hacks and currently identified stubs I can check out and work from?
I think I understand the project topology well enough now to compile a hello world test and run it on metal.
All the emulation stuff for 1300D is in the "main" qemu branch.
https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-tests/lastSuccessfulBuild/console - look up 1300D
https://builds.magiclantern.fm/jenkins/view/QEMU/job/QEMU-1300D/
Yeah I checked out that branch earlier.
Realised id not backed up my ROM copies so ill redo that shortly.
Hoping some of kennetrunners stubs progress might have been recorded in one of the build branches, but no matter, still needs doing.
@anyone else. Dont expect rapid progress here. Im going to have to properly learn this stuff as I go, im no reverse engineering genius :)
How to edit or extract firmware of canon 1300D .FIR File format?
Is there any tool available?
Top of page -> Downloads -> Download Nightly Builds -> Scroll down to "ROM dumpers"
A request to admin/mod /post owner
Please edit the main thread for all related updates on the 1300d.
so that we don't have to dig in all the posts.
please, just a request.
also, need to know is it possible to connect mic using USB port of 1300d ???
Compile the required information into a single post and I'll happily transfer it to the opening post.
I tried running DUMP1300.FIR on my recently purchased 1300.102. It takes quite a long time and results in
a7b9cc485a85b94448bbda6a6bb9e428 ROM0.BIN
f53fb78da3de0089f9d14d1fd904c1da ROM1.BIN
However, ROM0.MD5 reads:
b7bd14aa3245c539d5327434be9e0e4b ROM0.BIN
(ROM1.MD5 is a match). I tried twice with identical outcomes.
That's OK - it means ROM0 is not connected (http://www.magiclantern.fm/forum/index.php?topic=6785.msg58899#msg58899) physically (all you get in the dump is electrical noise).
This is true for most (if not all) Rebel models; the dumper is "one size fits all", so it tries to save both ROMs regardless.
edit: doesn't apply to 1300D; ROM0 has valid contents here, and ROM0.MD5 matches my dump; try this workaround (http://www.magiclantern.fm/forum/index.php?topic=19417.msg183579#msg183579). edit2: false alarm?!
Quote from: a1ex on November 05, 2017, 01:41:13 AM
This is true for most (if not all) Rebel models
Thanks, although I'm not sure what "Rebel models" mean, since I've got plain old 1300D ;-)
Anyway, should I upgrade to 1.1.0? It seems there had been some progress on porting ML there, but would I be able to downgrade later on?
https://en.wikipedia.org/wiki/Canon_EOS#Naming_scheme
The firmware-specific bits from ML repo (https://bitbucket.org/hudson/magic-lantern/src/cc49f782ad83/contrib/qemu/scripts/1300D/?at=qemu) are at 1.1.0. That's just a few stubs, so if there is a newer firmware available, it's easiest to upgrade at this stage (not later).
Hey guys, I'm writing for advice!. I've had a T1i for the longest time and I love it. I thought it was time for an update and bought a T6, only to find out today ML is not yet available for it.
I already had a online ad placed for my T1i. Now I'm considering taking it down and put one up for the T6 instead. I know the improvements are mainly in video resolution and wifi connectivity. But tho that would seriously make my life easier, on the other hand I would lose a little water proof resistance, better build and infra red sensor.
I've came to the conclusion i will sell the T6 If ML is not available for it. And since you guys are the experts I wanted to ask you all. Should I hold my horses and hang on to the hope of a ML release? How are things looking so far?
I'm sorry if I'm being impertinent and not actually providing any help. Im short on money and I thought it would be best to ask.
Thanks in advance
Update: emulation now boots Canon GUI (https://bitbucket.org/hudson/magic-lantern/commits/7f1a436c204015628f51f931069eae2a43be8fcc)!
(http://builds.magiclantern.fm/jenkins/view/Experiments/job/QEMU-tests/ws/qemu/tests/1300D/menu2.png) (http://builds.magiclantern.fm/jenkins/view/Experiments/job/QEMU-tests/ws/qemu/tests/1300D/menu3.png)
What does this mean?
The 1300D, also being a DIGIC 4, is right now the easiest to port ML on - looking forward to seeing your Hello World!
For the impatient: QEMU guide (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/), installation video for Ubuntu (https://twitter.com/autoexec_bin/status/913530810686418944), for Mac (http://www.magiclantern.fm/forum/index.php?topic=16012.msg191686#msg191686) and guide for Windows (http://www.magiclantern.fm/forum/index.php?topic=20214.0).
Next steps: dfort's porting tutorial (http://www.magiclantern.fm/forum/index.php?topic=19417.0) and the EOS M2 walkthrough (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185084#msg185084).
Q: If it's so easy, why don't you do this ML port and call it a day?
A: Every camera has its own quirks - somebody has to sit down and find them, see what works, what not and so on. I could easily do an initial ML port in the emulator, with menus working, but that would kill all the fun from the potential 1300D developer - besides, I don't like doing things alone.
Have fun!
sorry for my silliness but, is the ML ported on 1300d yet? just a bit confused after all these posts..
That is mighty encouraging, after so long with little visible activity.
I'll take a browse of the material; I'm not sure I'm ready to be a developer for it.
hey a1ex,
i tried to dump the firmware, but got different md5 sums
the ROM0 i got the same MD5 dmitrys got: b7bd14aa3245c539d5327434be9e0e4b
the ROM1 I got a totaly different MD5: a34ed91ac69e2a73bc6689709c37f755/b00208bc8040358280f574711adcc51d
i used your dumper script, which is linked to on the nighlybuild page (http://www.magiclantern.fm/forum/index.php?topic=17969.msg172875#msg172875).
I used a 8GB and an 256MB SD card to verify that my cards are not somehow the reason. How can i run the "generic" dumper on my vanilla 1300D camera? or is it the same code?
I do not get it to work on qemu as well. the console logs:
./run_canon_fw.sh 1300D
DebugMsg=0xFE11F394 (from GDB script)
Lockdown read 0
Lockdown read 0
Lockdown read 1
Lockdown read 1
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 1FFFFFFF: eos.ram
40001000 - 5FFFFFFF: eos.ram_uncached
F0000000 - F1FFFFFF: eos.rom0
F2000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F9FFFFFF: eos.rom1
FA000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.iomem
[EOS] enabling code execution logging.
[EOS] loading './1300D/ROM0.BIN' to 0xF0000000-0xF1FFFFFF
[EOS] loading './1300D/ROM1.BIN' to 0xF8000000-0xF9FFFFFF
[MPU] warning: non-empty spell #12 (PROP 80030040) has duplicate(s): #11
[MPU] warning: non-empty spell #13 (PROP_CARD2_STATUS) has duplicate(s): #49
[MPU] warning: non-empty spell #35 (PROP_VIDEO_MODE) has duplicate(s): #36
[MPU] Available keys:
- Arrow keys : Navigation ...
but the gui does not show up. Do i need a special parameter on the ./run_canon_fw.sh? i only used ./run_canon_fw.sh 1300D.
thx in advance
User settings are saved in the ROM (usually ROM1), so it's actually very difficult to get identical MD5 for this one. Not sure if clearing Canon settings does the trick (probably not, as the location of these settings also changes in the ROM).
Their role is to make sure the dumping process was successful (so if the checksum from ROM1.MD5 matches your ROM1.BIN, it's fine).
Full log? Also try running with -d debugmsg to see more messages.
yes the md5 of the rom1 is equal to the actual md5 of the rom1. The rom0.md5 is different, but as i get if from the other posts, the rom0 is not connected, so this is expected.
the parameter -debugmsg does not give other output. is there any other way, to get more debug output? i redownloaded all the magiclatern repo (hg clone .. ) and build all new, but still the same problems.
The output again:
./run_canon_fw.sh 1300D -d debugmsg
DebugMsg=0xFE11F394 (from GDB script)
Lockdown read 0
Lockdown read 0
Lockdown read 1
Lockdown read 1
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 1FFFFFFF: eos.ram
40001000 - 5FFFFFFF: eos.ram_uncached
F0000000 - F1FFFFFF: eos.rom0
F2000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F9FFFFFF: eos.rom1
FA000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.iomem
[EOS] enabling code execution logging.
[EOS] loading './1300D/ROM0.BIN' to 0xF0000000-0xF1FFFFFF
[EOS] loading './1300D/ROM1.BIN' to 0xF8000000-0xF9FFFFFF
[MPU] warning: non-empty spell #12 (PROP 80030040) has duplicate(s): #11
[MPU] warning: non-empty spell #13 (PROP_CARD2_STATUS) has duplicate(s): #49
[MPU] warning: non-empty spell #35 (PROP_VIDEO_MODE) has duplicate(s): #36
[MPU] Available keys:
- Arrow keys : Navigation
- PgUp, PgDn : Sub dial (rear scrollwheel)
- [ and ] : Main dial (top scrollwheel)
- SPACE : SET
- M : MENU (press only)
- P : PLAY (press only)
- I : INFO/DISP (press only)
- Q : guess (press only)
- L : LiveView (press only)
- A : Av
- Shift : Half-shutter
- B : Open battery door
- C : Open card door
- F10 : Power down switch
- F1 : show this help
[MPU] WARNING: forced shutdown.
For clean shutdown, please use 'Machine -> Power Down'
(or 'system_powerdown' in QEMU monitor.)
Forgot about this one, as no other camera requires this - reply #7.
On 1300D, ROM0 is connected (there is valid data if you open it with a hex editor), but since you've got the same MD5 as other users, it means there are no user-specific or calibration data in this ROM.
On most other Rebels, it's not, but 1300D is an unusual mix between DIGIC 4 and 6 (a lot closer to D4).
The ROM0.MD5 is different from the actual MD5 sum. is there a problem? or can i ignore this? should i try to dump, since i get the same md5?
Yes, that's why the MD5 is there. The file I/O routines from bootloader are not very robust - totally repeatable in QEMU, but not exactly deterministic on real hardware.
ok .. i totaly ignored the rom0 since i thought that is not connected .. i will try to get a correct dump .. thx for the help .. hope it works after that..
i tried it some more, but there is no way, to get it correct. Is there a "best" way to do it? I partitioned my 8gb cards to 256mb. Now the dumper do not finish at all. What are the problems, why the camera get wrong checksums?
UPDATE: I formated the SD Card fat16 and shrinked it a bit more (240mib). but still wrong md5:
user@morbo: /Volumes/Untitled% md5 ROM0.BIN && cat ROM0.MD5
MD5 (ROM0.BIN) = e913c61b9717324b2aa16f366586e081
b7bd14aa3245c539d5327434be9e0e4b ROM0.BIN
Best guess: caching issues (https://community.arm.com/processors/b/blog/posts/caches-and-self-modifying-code) (more details in the 80D thread).
What worked so far: dd the SD image that comes with QEMU (http://www.magiclantern.fm/forum/index.php?topic=19417.msg183579#msg183579).
You may also try emulating with the bad ROM - with some luck, it may work. Don't forget #7.
ok .. i found the problem, why the dump did not run in qemu .. after reading the forum again. i found this post (http://www.magiclantern.fm/forum/index.php?topic=17969.msg172893#msg172893)
Quote- 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:
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.
now i get the gui in qemu. Thx for the help. Now we can work with that.
So i started finding stubs in the ROM. A1ex can you have a look if this offsets make sense.
/** Startup **/
NSTUB( ROMBASEADDR, firmware_entry ) // 0xF8010000
NSTUB(0xFE0C3A24, cstart)
NSTUB(0x00029898, bzero32)
NSTUB(0xFE0C3AF8, create_init_task)
NSTUB(0xFE1296C8, init_task)
NSTUB( 0x61123, additional_version)
NSTUB(0xFE11F394, DryosDebugMsg)
NSTUB( 0x38FC, task_create)
/** File I/O **/
NSTUB(0xFE2A43FC, FIO_CloseFile)
NSTUB(0xFE2A53D0, FIO_FindClose)
NSTUB(0xFE2A52F0, FIO_FindNextEx)
NSTUB(0xFE2A41AC, _FIO_ReadFile)
NSTUB(0xFE2A425C, FIO_SeekSkipFile)
NSTUB(0xFE2A434C, _FIO_WriteFile)
NSTUB(0xFE2A4C3C, _FIO_CreateDirectory)
NSTUB(0xFE2A4058, _FIO_CreateFile)
NSTUB(0xFE2A51FC, _FIO_FindFirstEx)
NSTUB(0xFE2A4578, _FIO_GetFileSize)
NSTUB(0xFE2A3F9C, _FIO_OpenFile)
NSTUB(0xFE2A4104, _FIO_RemoveFile)
NSTUB(0xFE2A4A74, _FIO_RenameFile)
What is the minimum stubs i need to find (and which) so i can test, if i can run ml in qemu?
I copied the 1100D folder in ml/platforms to a new 1300D and poked around in some files. I can run the code, but some stub is not correct. How can i enable an hello world only ml build? is there a tutorial, i did not find?
Yes, they make sense. Some of the functions will have to be called from RAM (like task_create); if they are in the block copied at 0x1900 (-d romcpy), try that address first.
There are two kinds of hello world: the minimal target (without any ML features, but you can call any Canon code and test your stubs/consts), and CONFIG_HELLO_WORLD on the full ML codebase. You can also compile without features, follow compiler errors to see what stubs you need, then enable them one by one.
Tutorials linked earlier in this thread; QEMU docs (and QEMU itself) are actively updated.
so i managed to get code runing. i hooked up the restart.c file, and get my own code runing. But the copy of the ml code and the restart does not work. it always crashes. How do i find the BSS and therefor the RESTARTSTART value? i used the same the 600D does (which is 0x00082000/0x00C80100). is it guessing for empty space, or can i find a structure there, where i can read the address from?
Have you already looked here?
Quote from: a1ex on December 22, 2017, 11:42:15 PM
Next steps: dfort's porting tutorial (http://www.magiclantern.fm/forum/index.php?topic=19417.0) and the EOS M2 walkthrough (http://www.magiclantern.fm/forum/index.php?topic=15895.msg185084#msg185084).
Things changed a bit since writing the walkthrough (old methods still work, but now there's an easier way): you can now get the same info (http://www.magiclantern.fm/forum/index.php?topic=15895.msg186872#msg186872) from the serial console (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst#rst-header-dryos-internals) in QEMU ("meminfo -m" at Dry-shell console). Just like M2, you can use the "classic" boot process only for minimal target and
maybe for the "full" hello world; we'll have to find some other place to load ML (CONFIG_ALLOCATE_MEMORY_POOL or something else). We still need the "classic" boot process for the installer, and the minimal hello world will certainly work with it, so don't give up yet.
There is a
possibly unused (not tested) free memory block here (http://www.magiclantern.fm/forum/index.php?topic=5071.msg186876#msg186876).
ok .. i am a bit further .. i can start code. but when ml tries to start the init_task i get an error:
DRYOS PANIC: Module Code = 1, Panic Code = 4
do you have a list, what the panic codes mean? i traced it down to the function sub_FEA8A450 which looks like it copies some basic structure and then checks if some checksum is correct. and then returns -1.
In the ml code it is right after the
void (*ram_cstart)(void) = (void*) &INSTR( cstart );
ram_cstart();
i verified, everything seams correctly patched ..
it is to late now, to look any further.. will continue tomorrow.
More likely, you have overwritten some of the DryOS data structures. No idea what the DryOS panic codes are, but you shouldn't need them - that points to memory corruption or invalid code executed somehow.
If you have the source code online somewhere, I can check it.
Digging up my notes (which I still cant find) whet my appetite. 1300D Firmware booted in QEMU.
Time to remember stuff.
OK so it seems to compile minimal for the 1300D we need to find the stubs
bmp_vram_info
msleep
*dig dig dig*
Thought id found them but running the minimal hello world in QEMU's just looping
PrefetchAbort
0007F158
So either ive stuffed what I found or one of the other stubs is wrong (sic)
// Note / Question
Just to be sure, im supposed to be copying the compiled autoexec.bin file to sd.img and running with boot=1 correct?
I am doing a checkpoint each test by setting boot=0 to ensure booting to GUI works as intended, just in case I stuff something else.
More:
OK im confident know there's something wrong other than incorrect msleep or bmp_vram_info stubs.
Removing them from the mix and running a copy of minimal which I would expect to simply die faults at the same point.
Meaning one of the main stubs is probably wrong. Or being called from RAM and we dont have an offset (tempted to go into work and get my laptop with my last efforts where I think I had something on that).
Taking a break and creating a public fork so nothing goes missing again.
Public Fork:
https://bitbucket.org/maugriman/magic-lantern-1300d/
Currently just the initial folder setup and currently identified stubs, with the framework copied from the 1100D
*sigh* reading through the EOSM2 walkthrough a1ex linked hinted I was having the same issue with GDB not properly loading with QEMU as dfort did.
Fixed, added a breakpoint for firmware start, going to add more for the non-FIO stubs so I can try and pinpoint where is going off target.
No idea what im doing, but im having fun doing it 8)
To debug, I recommend analyzing a memory trace (http://www.magiclantern.fm/forum/index.php?topic=15895.msg186246#msg186246), to see exactly what the binary does.
Just fixed some inconsistencies in QEMU when handling memory logging options, so make sure you upgrade QEMU to the latest commit to try the stuff below.
Recommended invocation:
. ./export_ml_syms.sh minimal/1300D
./run_canon_fw.sh 1300D,firmware="boot=1" -d calls,io,int,romr,ramw,autoexec
The logs are huge, but they let you identify all the actions of ML startup code (internal XOR check, copying blocks of code around in memory, zeroing out memory, patching Canon's startup code). I can publish a detailed analysis later if needed (with more details than in the EOS M2 post linked above). Just one trick that may be useful to narrow down such huge logs:
./run_canon_fw.sh 1300D,firmware="boot=1" -d calls,io,int,romr,ramw,autoexec |& grep -C 10 copy_and_restart
What issue did you have with gdb? 64-bit crashes, or something else? What operating system?
Hey, i am so far, that i get the ml bootup code running. but the CONFIG_ALLOCATE_MEMORY_POOL has the problem, that it copies the init code from the rom to the ram, but it is to far apart from the rom, that a normal BL does not work, to jump back to subs, it needs. I am trying to preconvent that by copying that code as well, but this is still broken.
i need to cleanup my code, to publish it ..will do that tonight.
For now my codeflow is this: (copy_and_restart() -> ram_cstart() -> my_init_task() -> init_task_patched() -> new_init_task()) this is where the problem starts.
The copy of the init task, which is patched in init_task_patched() has the wrong offsets, so it cannot jump back to rom. (but only on some functions. A thing i noticed, is if the offset is > 0x800000 it will jump to rom, if it is smaller, it will jump to the offset itself. Therefor there is a gab we cannot jump to :/ any ideas?) next step will be create a jump table next to the init function and try to jump via register jumps
btw
i found this functions stub
NSTUB(0xFE0180A8, print_serial)
extern int print_serial(const char* s, ...);
which does print to serial.
Bitbucket is down at the moment.. so i cannot upload my code there ..
alex do you have any suggestions to this error: it comes from the relocate script, which copies init_task and createInitTask.
Fixing from FE1296C8 to FE1298AC
FE1296D0: EBFE5CDE BL FFFE5CDE => FE0C0A50
FE1296D0: !!!! can not fixup jump from 0010232C to FE0C0A50 (offset -00810639)
FE1296F4: EB00006D BL 0000006D => FE1298B0
FE129704: EBFE692E BL FFFE692E => FE0C3BC4
FE129704: !!!! can not fixup jump from 00102360 to FE0C3BC4 (offset -0080F9E9)
FE129718: EBFE6960 BL FFFE6960 => FE0C3CA0
FE129718: !!!! can not fixup jump from 00102374 to FE0C3CA0 (offset -0080F9B7)
FE12972C: EBFE6B8C BL FFFE6B8C => FE0C4564
FE12972C: !!!! can not fixup jump from 00102388 to FE0C4564 (offset -0080F78B)
FE12973C: EB0673CD BL 000673CD => FE2C6678
FE12974C: EBFE5E80 BL FFFE5E80 => FE0C1154
FE12974C: !!!! can not fixup jump from 001023A8 to FE0C1154 (offset -00810497)
FE129760: EAFE60FE B FFFE60FE => FE0C1B60
FE129760: !!!! can not fixup jump from 001023BC to FE0C1B60 (offset -00810219)
FE129770: EB7B63AD BL 007B63AD => 0000262C
FE129780: EAFE5DF0 B FFFE5DF0 => FE0C0F48
FE129780: !!!! can not fixup jump from 001023DC to FE0C0F48 (offset -00810527)
FE12979C: 7A697320 B 00697320 => FFB86424
FE129814: 745F7469 LD 7, 15, ' => FE1293B3: 745F7164 356 data=812014E5
FE129830: EB066FA7 BL 00066FA7 => FE2C56D4
FE129844: EB066F8F BL 00066F8F => FE2C5688
FE129854: E51F6050 LD 6, 15, 80 => FE1298AC: E51F61A0 416 data=FE884A48
FE12987C: EB066FF3 BL 00066FF3 => FE2C5850
Fixups=10231C entry=102324 free_space=8
Fixing from FE0C1B60 to FE0C1EB8
FE0C1B6C: EBFFFDB5 BL FFFFFDB5 => FE0C1248
FE0C1B6C: !!!! can not fixup jump from 00102554 to FE0C1248 (offset -008104C5)
FE0C1B70: EB015F55 BL 00015F55 => FE1198CC
FE0C1B7C: EB01961C BL 0001961C => FE1273F4
FE0C1B80: EB7D0641 BL 007D0641 => 0000348C
FE0C1B8C: EB7D090E BL 007D090E => 00003FCC
FE0C1B9C: EB7D0667 BL 007D0667 => 00003540
FE0C1BA0: EB01795A BL 0001795A => FE120110
FE0C1BBC: EB7D0300 BL 007D0300 => 000027C4
FE0C1BE4: EB7D0353 BL 007D0353 => 00002938
FE0C1C0C: EB7D03BE BL 007D03BE => 00002B0C
FE0C1C30: EB7D042B BL 007D042B => 00002CE4
FE0C1C44: EB7D081C BL 007D081C => 00003CBC
FE0C1C48: EB017DD3 BL 00017DD3 => FE12139C
FE0C1C50: EB019C21 BL 00019C21 => FE128CDC
FE0C1C60: EB017AE3 BL 00017AE3 => FE1207F4
FE0C1C64: EB01885A BL 0001885A => FE123DD4
FE0C1C6C: EB018094 BL 00018094 => FE121EC4
FE0C1C70: EB017CDB BL 00017CDB => FE120FE4
FE0C1C74: EB01897A BL 0001897A => FE124264
FE0C1C78: EB0189C2 BL 000189C2 => FE124388
FE0C1C84: EB0187D7 BL 000187D7 => FE123BE8
FE0C1C88: EB0187EA BL 000187EA => FE123C38
FE0C1C94: EB01807C BL 0001807C => FE121E8C
FE0C1CA0: EB018079 BL 00018079 => FE121E8C
FE0C1CAC: EB018076 BL 00018076 => FE121E8C
FE0C1CB8: EB018073 BL 00018073 => FE121E8C
FE0C1CC4: EB018070 BL 00018070 => FE121E8C
FE0C1CD0: EB01806D BL 0001806D => FE121E8C
FE0C1CDC: EB01806A BL 0001806A => FE121E8C
FE0C1CFC: EB01750D BL 0001750D => FE11F138
FE0C1D08: EB01767B BL 0001767B => FE11F6FC
FE0C1D10: EB7D07F7 BL 007D07F7 => 00003CF4
FE0C1D18: EBFFFC67 BL FFFFFC67 => FE0C0EBC
FE0C1D18: !!!! can not fixup jump from 00102700 to FE0C0EBC (offset -00810613)
FE0C1D34: EB017596 BL 00017596 => FE11F394
FE0C1D48: EB017591 BL 00017591 => FE11F394
FE0C1D50: EB013313 BL 00013313 => FE10E9A4
FE0C1D70: EB0047FE BL 000047FE => FE0D3D70
FE0C1D70: !!!! can not fixup jump from 00102758 to FE0D3D70 (offset -0080BA7C)
FE0C1D78: E51F4848 LD 4, 15, 0 => FE0C1538: E51F4230 560 data=000310AC
FE0C1D90: 1B01757F BL 0001757F => FE11F394
FE0C1D9C: EB00488A BL 0000488A => FE0D3FCC
FE0C1D9C: !!!! can not fixup jump from 00102784 to FE0D3FCC (offset -0080B9F0)
FE0C1DA0: EB0177FA BL 000177FA => FE11FD90
FE0C1DA4: EB017494 BL 00017494 => FE11EFFC
FE0C1DA8: EB0190C9 BL 000190C9 => FE1260D4
FE0C1DAC: EB001112 BL 00001112 => FE0C61FC
FE0C1DAC: !!!! can not fixup jump from 00102794 to FE0C61FC (offset -0080F168)
FE0C1DB0: EB019E9B BL 00019E9B => FE129824
FE0C1DCC: EB7D06CA BL 007D06CA => 000038FC
FE0C1EA4: 6B736154 BL 00736154 => FFD9A3FC
FE0C1EB0: E51F1980 LD 1, 15, . => FE0C1538: E51F1364 868 data=000310AC
Fixups=102540 entry=102548 free_space=8
I added the checker, if we can reach the RAM, which does not trigger any error.
/* relative jumps in ARM mode are +/- 32 MB */
/* make sure we can reach anything in the ROM (some code, e.g. patchmgr, depend on this) */
uint32_t jump_limit = (uint32_t) &_bss_end - 32 * 1024 * 1024;
if (jump_limit > 0xFF000000 || jump_limit < 0xFC000000)
{
print_serial("[BOOT] warning: cannot use relative jumps to anywhere in the ROM (limit=%x)\n", jump_limit);
i will check there any further..
That's ugly. You can work around simple jumps, by replacing B 0xFE001234 with LDR PC, =0xFE001234 and save that constant in the "fixups" area, but I'm not sure how to do a long call with a single instruction.
That checker assumes up to 16MB ROM, like other DIGIC 4/5 models; 1300D has a 32MB ROM.
Luckily, on DIGIC <= 5 you can patch arbitrary stuff in ROM without relocating: try the HIJACK_CACHE_HACK boot method, similar to 600D. That camera also loads ML in the AllocateMemory pool, but does not use the "classic" way to relocate the code.
(side note: for DIGIC 6 I have to do something about the patchmgr code, as it has similar issues, so that checker should probably go away soon)
i already tried that .. it starts my code but breaks with an exception in the filemgr ..
< Error Exception>
TYPE : 4
ISR : 0
TASK IDSR : 1318396
TASK Name : FileMgr
R 0 : 6cfe0c08
R 1 : 84fe0c08
R 2 : b0fe0c08
R 3 : cc000004
R 4 : 34fe0c08
R 5 : 4c0010b0
R 6 : 10b0
R 7 : 0
R 8 : 0
R 9 : 0
R10 : 0
R11 : 0
R12 : 0
R13 : 4f4ac
R14 : 0
PC : 0
CPSR : c8100008
qemu: fatal: Trying to execute code outside RAM or ROM at 0xe59ff010
i am investigating that .. lets see, where this path breaks..
so fixed that backup code thingie ..
(http://thumb.ibb.co/icaLBm/Screen_Shot_2018_01_09_at_21_21_50.png) (http://ibb.co/icaLBm)
all i had to do, was fix the offsets. no additional patching required .. here is my ml/platform/1300D.110 folder.
https://www.ultrachaos.de/share/1300D.110/
I basicaly copied the 600 to the 1300. in the stubs.S file i indented every old offset by one space. so i can see the old offsets when i search for new ones (i have the code for the 600 as well, so it is easyer to spott the stubs)
will work there further to find all the stubs .. and fix some internals.h and consts.h. This code should run as is in qemu did not try on an actual camera as of now, because mine does not have the bootflag set yet. Will look into that later.. Try to get the hello world running.
Mein Gott DeinGott (sorry I had to), thats a leap forward.
Ive copied your work into the repo and also made some adjustments to get CONFIG_HELLO_WORLD to compile (fps-engio and raw had some platform-specific requirements)
Hello World now builds, and autoexec.bin is loaded as you had, but Hello World does not execute.
I grabbed the QEMU output for a run and popped it up here
<REMOVED DUE TO MERGE WITH MAIN REPO>
if anyone wants to have a sticky. File is qemu-bootlog-hw.txt
Sorry did not copy the 1300D changes to compile the HELLO World. But i see you already found the code. i only copied it from other cameras.
i am working on that hello world. some offsets seam broken. i narrowed the problem down to the is_dir function and there the FIO_FindFirstEx function call, the stub should point to the correct place (0xFE2A51FC, if someone can verify). But it looks as if we cannot execute that function i always get an exception at pc ff1f94d8. I added some debug print output to the beginning of the functions. But Ida does not stop in FIO_FindFirstEx. I am investigating that.
start MY BIG INIT
start _find_ml_card
start is_dir
Searching for A:/ML
< Error Exception>
TYPE : 4
ISR : 0
TASK IDSR : 50135115
TASK Name : ml_init
R 0 : 2fa9874
R 1 : 1ff
R 2 : 10aadc
R 3 : 1a9874
R 4 : 11de24
R 5 : 10ab88
R 6 : 10ab11
R 7 : 212
R 8 : 108506
R 9 : 19980198
R10 : 19980218
R11 : ff
R12 : 19980218
R13 : 1a9860
R14 : d157c
PC : ff1f94d8
CPSR : 13
1406: 736.000 [STARTUP] ###exceptionhandlercbr 0xff1f94d8 0
1407: 737.280 [STARTUP] #####exceptionhandlercbr 0xff1f94d8
1430: 737.536 [STARTUP] Exception : Time 2017/9/30 13:15:0
If you identified FIO_FindFirstEx from the BL call just before the debug message *"[DM] ERROR : FIO_FindFirstEx fail"
at ROM dump position
0xf842435c -> 0xf8424368
Then I would concur that it seems the likely candidate.
ok .. i got the hello world to run, but it does not show anything on the screen .. the last output on the serial:
[DM] FROM Write Complete!!!
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 314
ASSERT : SystemIF::KerSem.c, Task = ml_init, Line 354
HELLO WORLD
firmware signature = 0xCD13B11F
firmware signature = 0xCD13B11F
(i patched it to print to serial, can check that code in as well, but it is only 1300 so not sure if it only clutters the source)
a1ex what stubs do i need to set for the printing (hello worls) how do i find the offsets for the fonts for example? i think there is the problem still. other question does the hello world draw in front of other stuff or do i have to diable the screen somehow? right now it shows the configuration screen. not the menu.
Maybe either create a new branch for 1300D-experimental code (regarding your serial patch) or wrap it in a new define check?
CONFIG_QEMU_SERIAL_DEBUG or something?
it is not QEMU special .. but i will make it include it and make it save for the other cameras .. :)
regarding the FONTS .. i found them, but still no output on the screen :/ .. i start to question the memory buffers and stuff .. do you or anyone else have an inside into this? a1ex what do we need to have the output right. The disp_direct.c works in restart.c. Is it possible, that i have to disable the "default" screen first?
(https://www.ultrachaos.de/share/Screen-Shot-2018-01-11-11-28-06/Screen-Shot-2018-01-11-11-28-06.png)
so.. i pushed the print_serial. i made it a macro, which will just be nulled, if CONFIG_HAS_PRINT_SERIAL is not set. it will print to serial (even on the real camera it would).
I added some more stubs. But still the gui does not show anything. i think that there is still some things in const.h missing/wrong. will look into this tomorrow.
at last:
(https://www.ultrachaos.de/share/Screen-Shot-2018-01-12-00-01-23/Screen-Shot-2018-01-12-00-01-23.png)
the code is pushed to the repo: https://bitbucket.org/maugriman/magic-lantern-1300d
Well Three Cheers for DeinGott!
As I understand it, the next step is to get one of the primary Dev's to generate a boot-flag enabler (the installer?) the then effectively try this on real hardware.
Im a willing test dummy here. Im comfortable with the risk inherent :)
ok .. i first have to fix the malloc call. This still gets an assert triggered. Which should not happen, as i guess. But otherwise this looks prommising..
OK .. narrowed it down to mem.c and the __mem_malloc function .. the problem is, that the memory is somehow not initialized (mem_init). i have to investigate why this is so, but calling the mem_init when the mem_sem is not set, fixed the exception.
Could it be timing? I note in QEMU we reach the GUI a good 10-12 seconds before anything else runs. And even vanilla we see a pause then further startup occur just after the GUI presents
that is because the ml_gui_initialized is not called for some reason. this causes a timeout .. (see boot-hack.c function my_init_task at the bottom)
Then if im following the startup properly (im pretty raw at this sorry) then given that
ml_gui_initialised
flag is set via function
handle_common_events_startup
in
gui-common.c,
which is called from
handle_buttons
in
gui.c
which is part of the ML gui_main_task, it would follow that said task is either not being started, or is faulting.
Which could be a incorrect stub for the dryos gui_main_task
I might check that out.
Or not. I see you're on top of it. #standsback
ok .. one problem was an old RESTARTSTART address.
check on that later. :) one error is gone now :)
ok .. problem might be, hello_world does not overwrite this task :) I will try without the strings attached :)
Great progress!
Imported the 1300D branch in the main repo. Also merged a couple of experimental branches: lua_fix (which has the memory init fix and many other backend changes waiting to be tested (http://www.magiclantern.fm/forum/index.php?topic=14828.msg194706#msg194706)), qemu (useful for qprintf (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst#rst-header-using-qprintf-and-friends)), 1200D (so you can reuse any tweaks from there) and new-dryos-task-hooks (https://bitbucket.org/hudson/magic-lantern/pull-requests/672/dryos-task-hooks-for-newer-cameras-6d-70d/diff). I expect these to land into mainline before 1300D, so they should not cause any trouble. You should be able to sync with:
hg pull -r 1300D https://bitbucket.org/hudson/magic-lantern
Regarding the latter: there are old-style DryOS task hooks (DIGIC 4 and older DIGIC 5), new-style (6D, 70D, 100D, EOSM2) and there's 1300D (which is clearly not using old-style task hooks, but doesn't work out of the box with the new style ones either) - edit: sorted out! fixed task_dispatch_hook and 1300D is in the same group as the newer D5 models.
You can now see DryOS tasks switching if you compile with CONFIG_QEMU=y and you enable DEBUG_TASK_HOOK in boot-hack.c. Without the latter, only new tasks will be displayed.
Without CONFIG_HELLO_WORLD, it also reacts to the delete button (Av) and attempts to open ML menu :D
In any case, you've now got a bunch of additional debug info to work with, and hopefully a slightly cleaner codebase. GDB symbols too.
Please find a (very hackish) patch for QEMU that allows you to log the calls made by ML into Canon firmware:
qemu-log-stubs.patch (http://a1ex.magiclantern.fm/bleeding-edge/qemu/qemu-log-stubs.patch)
Using this patch, I've checked the calls made by ML (with CONFIG_HELLO_WORLD). Full log: 1300D-hello-world.txt (http://a1ex.magiclantern.fm/bleeding-edge/1300D/1300D-hello-world.txt)
To see only the function calls:
cat 1300D-hello-world.txt | grep "call\|return\| -> 0x"
cat 1300D-hello-world.txt | grep "call\| -> 0x" | grep -o "0x[^(]*" | sort | uniq
This gives the minimal number of stubs required for Hello World, and a small number of stubs for me to double-check before running the first test on the camera.
Memory allocation check (GetMemoryInformation (http://www.magiclantern.fm/forum/index.php?topic=15895.msg187533#msg187533)):
Without ML: 0xa30000 0x1df8a4 (total and free)
With ML: 0x9b0000 0x15f898 (ok)
ml_reserved_mem 524288 (ok)
MemSiz 0x6f134 (ok)
Let's try: HELO1300.FIR (http://a1ex.magiclantern.fm/bleeding-edge/1300D/HELO1300.FIR) (md5 265b704a50875e9293cf5a1b00e8fd03)
thx for the fir. i am not home at the weekend. will test it on monday. (if anybody else wants, please post picture :) )
I found some more offsets i had to change :) .. you merged the stuff to the unifi branch? or only pulled the branches into the main repo?
Only pulled the branch; you may sync and continue from the current state. If you've already committed any local changes, you can add --rebase to the hg pull command (so you no longer need to merge afterwards).
(http://thumb.ibb.co/mMKymm/26905883_901121340050410_232047400_o.jpg) (http://ibb.co/mMKymm)
Results from HELO1300.FIR
Looks like it might say out of bound, but im guessing it would make sense to you :)
Right - the error handler tripped over a null pointer, so the camera must have locked up (but things were fine on the normal execution path). Updated the FIR with a workaround (#define DISPLAY_IS_ON 0):
HELO1302.FIR (http://a1ex.magiclantern.fm/bleeding-edge/1300D/HELO1302.FIR) (md5 c42c305883eb9f2914096f474233ea8d)
For troubleshooting:
cat 1300D-hello-world.txt | grep FIO
We should wait a little more before enabling the boot flag...
(http://thumb.ibb.co/bxoahR/26853407_901184476710763_1480366753_o.jpg) (http://ibb.co/bxoahR)
Nice. Is the different firmware signature on hardware vs emulation expected?
It must be modified by the cache hacks; let's try to disable them after booting (unable to test this one in QEMU):
HELO1303.FIR (http://a1ex.magiclantern.fm/bleeding-edge/1300D/HELO1303.FIR) (md5 656baf799707e574b71d66b4670cd001)
Please upload a screenshot without error and with correct fonts, so I can announce it on Twitter.
OK, HELO1303.FIR plus a base compile of ML so we have fonts and other artifacts
(http://thumb.ibb.co/nu10Gm/26855944_901202163375661_359778501_n.jpg) (http://ibb.co/nu10Gm)
GUI stuck around this time. Did reset and try again just in case.
FW Sig changes again but still different from QEMU result (which both DeinGott and I matched on, hopefully ruling out a bad ROM on any side)
Should I be seeing debug/output logs into a file on the SD card?
hg blame src/fw-signature.h | grep 1300D
Are you able to navigate the menus and use the camera normally?
No debug logs enabled.
Menu nav no issues. Changing menu option (image qual) saving, turn off/on, confirm still set, reload HW, still set (config writes working)
LiveView working normally. Took a photo, scared myself because I was set to 8s expose and thought it had crashed, file saved onto SD no issue.
Yep, all looks fine. And HW shows back up straight up on any change.
No issue on debug, just checking incase I should expect it and there was a FIO write problem.
Gotcha on firmware sig
congrats ;D
Hey A1ex,
When I was going over your published your commit https://bitbucket.org/hudson/magic-lantern/commits/77336969687da991a4d87269d3260f67a00e829e?at=1300D (https://bitbucket.org/hudson/magic-lantern/commits/77336969687da991a4d87269d3260f67a00e829e?at=1300D)
I noticed
+# no 1300D firmware yet?
+CANON_NAME_FIR = 5D300133.FIR
+FIRMWARE_ID = 0x80000404
Canon did post the current 1.1.0 to their site a little while ago:
http://support-in.canon-asia.com/contents/IN/EN/0400290302.html (http://support-in.canon-asia.com/contents/IN/EN/0400290302.html)
so confirmed on my hw as well. Did not upload the ml files to the card. So missing ml files :)
(https://thumb.ibb.co/mDGPe6/IMG_0263.jpg) (https://ibb.co/mDGPe6)
but still different from qemu: hw: 0x3d8461b5 vs qemu: 0xCD12E936 .. am i correct that the qemu variant is tainted by the cache hack? and we should update the signature in src/fw-signature.h
Quote from: DeinGott on January 14, 2018, 10:30:53 PM
...we should update the signature in src/fw-signature.h
Yes, the same thing happened to me on the EOSM2. AFAIK QEMU skips the firmware signature so it will still work.
@DeinGott: were you able to sync your source with my changes?
hg pull --rebase -r 1300D https://bitbucket.org/hudson/magic-lantern
hg up 1300D -C
hg blame src/fw-signature.h | grep 1300D
The cache uninstallation trick (done for HELO1303.FIR) is not committed; it was a cache_unlock(); sync_caches(); added at the top of my_big_init_task. I want to apply this one on all other models booting with this method.
Besides, QEMU is unable to emulate the cache hack uninstallation, so even with the above, the signature will be computed correctly in reboot.c (where it's needed to boot), but it would be displayed as in #147. I should fix that somehow in the emulation.
@dfort: the M2 signature issue was fixed; check c33141cd12a9 and the (updated) guide.
@shadowlab: thanks, I couldn't find it on Canon Europe a few days ago; now it's there...
since i code a bit more, i forked the repo to my own bitbucket.
https://bitbucket.org/shorst/magic-lantern
so yes the merge were successfull :)
i still have a problem to find the STATE objects. Do you have any easy way to find them?
#define DISPLAY_STATEOBJ (*(struct state_object **)0x2480) // posible: 0x000318C8
#define EVF_STATE (*(struct state_object **)0x3737C) // hope this is correct
#define MOVREC_STATE (*(struct state_object **)0x5720) // still 600D
#define SDS_FRONT3_STATE (*(struct state_object **)0x3660) // still 600D
btw. Still get some errors, but the ml menu is loading
(https://www.ultrachaos.de/share/Screen-Shot-2018-01-15-22-10-25/Screen-Shot-2018-01-15-22-10-25.png)
if someone knows howto get rid of the SYMBOLS not found error (the file is on the sd)
(https://www.ultrachaos.de/share/Screen-Shot-2018-01-15-22-14-36/Screen-Shot-2018-01-15-22-14-36.png)
stefan@morbo-3: ~/Develop/qemu% l /Volumes/EOS_DIGITAL/ML/modules/1300D_110.sym
-rwxrwxrwx 1 stefan staff 34K 15 Jan 22:13 /Volumes/EOS_DIGITAL/ML/modules/1300D_110.sym
Quote from: DeinGott on January 15, 2018, 06:46:30 PM
i still have a problem to find the STATE objects. Do you have any easy way to find them?
Got a bunch of them for the other models: https://a1ex.bitbucket.io/ML/states/index.html
These should be called by CreateStateObject; first argument is a string with their name, so they should come up in QEMU with -d calls. Let's try:
./run_canon_fw.sh 1300D,firmware="boot=0" -d calls |& grep --text EvfState
call 0xFE2BEA5C(fea7f8a2 "EvfState", 0, fe8b2260, e) at [Startup:fe1a3d20:fe0de6b8]
Okay, so CreateStateObject is 0xFE2BEA5C.
./run_canon_fw.sh 1300D,firmware="boot=0" -d calls |& grep --text 0xFE2BEA5C
(many state objects created)
We need to know where the pointers to these state objects are stored. Let's try logging RAM writes right after CreateStateObject returns. This function calls a couple of others, so it's not easy to grep these logs; let's try a custom GDB logging hook (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst#rst-header-debugging-with-gdb):
b *0xFE2BEA5C
commands
silent
print_current_location
printf "CreateStateObject(%s, 0x%x, %d, %d)\n", $r0, $r2, $r3, *(int*)$sp
# note: I could have used log_result instead of this block, but wanted to get something easier to grep
tbreak *$lr
commands
silent
print_current_location
printf "CreateStateObject => %x at %x\n", $r0, $pc
c
end
c
end
Invocation:
./run_canon_fw.sh 1300D,firmware="boot=0" -s -S & arm-none-eabi-gdb -x 1300D/debugmsg.gdb
...
[ Startup:fe12d9b8 ] CreateStateObject(SCSState, 0xfe8a80a4, 20, 12)
Temporary breakpoint 13 at 0xfe12d9bc
[ Startup:fe127b1c ] CreateStateObject => 796c50 at fe12d9bc
...
We expect a memory write right after CreateStateObject returns, so let's try grep:
( ./run_canon_fw.sh 1300D,firmware="boot=0" -d ramw -s -S & arm-none-eabi-gdb -x 1300D/debugmsg.gdb ) |& grep --text CreateStateObject -A 1 | grep 'CreateStateObject\|ram'
...
[ Startup:fe12d9b8 ] CreateStateObject(SCSState, 0xfe8a80a4, 20, 12)
[ Startup:fe127b1c ] CreateStateObject => 796d18 at fe12d9bc
[ram] at Startup:FE12D9BC:FE127B20 [0x00035A74] <- 0x796D18 : was 0x0;
...
Not a very pretty display, but should find most of them, as they are created during startup.
Some of these are no longer used in the source (such as SDS_FRONT3_STATE); I should clean them up.
You guys seem to have done a ton of work in my (several month) absense... :-)
I did some stub finding a while back, but much of it is written form in my notebook, which is at work - I'll dig that out tomorrow and share it.
Also - I got my dev environment created again and got the GUI displaying in QEMU - but not all the buttons work (no arrow keys for example) is this expected, or do people have it working fully in QEMU ?
Thanks .. Ken
Arrow keys are working here; QEMU identifies the keys from scancode, so look them up here: http://www.marjorie.de/ps2/scancode-set1.htm
Just noticed drive mode isn't working (DlgShootOlcDrive.c GetGuidanceIndex DriveMode err), but can be fixed easily with MPU_SPELL_SET_OTHER_CAM(1300D, 600D) in mpu.c, rather than 60D. Will commit that after updating the tests (not today). It's just a nitpick anyway (it won't interfere with porting ML).
edit: fix committed.
@DeinGott - about the symbols not found issue: this post might help https://www.magiclantern.fm/forum/index.php?topic=17969.msg183657#msg183657
Quote from: a1ex on January 15, 2018, 07:43:17 AM
@dfort: the M2 signature issue was fixed; check c33141cd12a9 and the (updated) guide.
Great. I'll try it out and report on the EOSM2 topic. BTW--great progress on QEMU. This last build went pretty much on autopilot.
a1ex i found all that were present in the state-object.h. (like three) are there more needed? did not scanl through all the code .. i am still investigating, why the state error occures
I still get an error in the Propmgr. But since i did not check that all the props are there and correct it is expected.
I've got a different address for EVF_STATE with the above commands:
[ Startup:fe1a3d20 ] CreateStateObject(EvfState, 0xfe8b2260, 14, 10)
[ Startup:fe127b1c ] CreateStateObject => 9334c4 at fe1a3d24
[ram] at Startup:FE1A3D24:FE127B20 [0x00037930] <- 0x9334C4 : was 0x0;
The PropMgr error is very interesting - PROP_HANDLER( PROP_MVR_REC_START ) in audio-common.c - it probably affects all other models without CONFIG_AUDIO_CONTROLS, but somehow ended up unnoticed. Some serious cleanup needed here.
Best guess: Canon's give_semaphore didn't throw an assertion on invalid semaphores in earlier firmwares - at least in 5D3, it just returns an error code without assert (so that invalid give_semaphore call was basically a NOP).
Ok with your method i have now a lot more States: :) thx ..
Dmstate: 0x39DD0
PropState: 0x38DB0
MFCMGRState: 0x39B50
EmState 0x36F24
FMnormalState 0x38558
SrmState 0x36FD0
Srmexmem1State 0x3702C
Srmexmem2State 0x37030
ScsState 0x35A74
ScseshutState 0x35A78
ScssrState 0x35A7C
SbsState 0x35AE8
SpsState 0x35B60
TomState 0x38500
FssState 0x36E94
AudioLevelStateSig 0x38CD0
SdsFrontState 0x36158
SdsFrontState 0x3615C
SdsFrontState 0x36160
SdsFrontState 0x36164
SdsFrontState 0x36168
SdsRearState 0x36078
SdsRearState 0x3607C
SdsRearState 0x36080
SoundEffetStateSig 0x38CDC
AsifState 0x38CF0
ActrlState 0x3D9DC
MovwState 0x3872C
MovrecState 0x38744
MovplayState 0x38750
MovrState 0x3BBE8
LvcdevState 0x37EE4
GmtState 0x933F68 // somehow off but valid
GmtMovieState 0x933F6C
GmtwakuState 0x933F70
EvfState 0x37930
ColorcalcState 0x380F8
AewbState 0x941C70
LvfaceState 0x37990
MotionDetectState 0x37DE8
MotionManagerState 0x94BB10
UsbControlPipe 0x6135C
UsbDataPipeBulkIn 0x61360
UsbDataPipeBulkOut 0x61364
UsbDataPipeInterupt 0x61368
UsbDeviceEvent 0x6136C
PtpdpsState 0x98D644
CeresState 0x38540
FcsState 0x36EA4
NwComState 0x3A504
MetactgState 0x3BC50
FrState 0xA478B4
FwState 0xA47AF0
VoiState 0x3BB34
SoundState 0x3BBCC
WavreaderState 0x40400
MrkState 0x3BB20
RdState 0x38124
DpState 0x371B4
DpimgeditState 0x3792C
InnerdevelopState 0x39C68
SasState 0x36270
SasState 0x36274
SasState 0x36278
SasState 0x3627C
SasState 0x36280
DisplayState 0x318B8
DisplayStateWithImgMute 0x318BC
is it posible they changed the way how they address the audio_ic? in powerSpeakerOnForWav they call it normaly like this:
ROM1_7:FF06A570 PowerSpeakerForWAV ; CODE XREF: PowerAudioOutput+24p
ROM1_7:FF06A570 STMFD SP!, {R4,LR}
ROM1_7:FF06A574 ADR R2, aPowerspeakerforwav ; "PowerSpeakerForWAV"
ROM1_7:FF06A578 MOV R1, #3
ROM1_7:FF06A57C MOV R0, #0x14
ROM1_7:FF06A580 BL DryosDebugMsg
ROM1_7:FF06A584 LDR R4, =byte_274C
ROM1_7:FF06A588 MOV R1, #0
ROM1_7:FF06A58C LDR R0, [R4,#(dword_2780 - 0x274C)]
ROM1_7:FF06A590 BL take_semaphore
ROM1_7:FF06A594 LDR R0, =0x5507
ROM1_7:FF06A598 BL _audio_ic_write
ROM1_7:FF06A59C LDR R0, =0x4903
ROM1_7:FF06A5A0 BL _audio_ic_write
ROM1_7:FF06A5A4 MOV R0, #0x4B00
ROM1_7:FF06A5A8 BL _audio_ic_write
ROM1_7:FF06A5AC LDR R0, =0x2713
ROM1_7:FF06A5B0 BL _audio_ic_write
ROM1_7:FF06A5B4 LDR R0, =0x271F
ROM1_7:FF06A5B8 BL _audio_ic_write
ROM1_7:FF06A5BC LDR R0, =0x4901
ROM1_7:FF06A5C0 BL _audio_ic_write
ROM1_7:FF06A5C4 ADD R0, R4, #0x58
ROM1_7:FF06A5C8 LDRB R0, [R0,#(byte_2A4F - 0x27A4)]
ROM1_7:FF06A5CC ORR R0, R0, #0x6B00
ROM1_7:FF06A5D0 BL _audio_ic_write
ROM1_7:FF06A5D4 LDR R0, [R4,#(dword_2780 - 0x274C)]
ROM1_7:FF06A5D8 LDMFD SP!, {R4,LR}
ROM1_7:FF06A5DC B give_semaphore
ROM1_7:FF06A5DC ; End of function PowerSpeakerForWAV
but on the 1300D it looks more like this:
ROM1:FE11CE60 PowerSpeakerForWAV ; CODE XREF: sub_FE11D1CC:loc_FE11D21Cp
ROM1:FE11CE60 ; SelectOutCheckFOut+68p
ROM1:FE11CE60 STMFD SP!, {R4,LR}
ROM1:FE11CE64 ADR R2, aPowerspeakerforwav ; "PowerSpeakerForWAV"
ROM1:FE11CE68 MOV R1, #3
ROM1:FE11CE6C MOV R0, #0x14
ROM1:FE11CE70 BL DryosDebugMsg
ROM1:FE11CE74 LDR R4, =unk_31B5C
ROM1:FE11CE78 MOV R1, #0
ROM1:FE11CE7C LDR R0, [R4,#(unk_31BA4 - 0x31B5C)]
ROM1:FE11CE80 BL takeSemaphore_ram
ROM1:FE11CE84 LDR R0, =unk_FE8CAC8C
ROM1:FE11CE88 BL sub_FE2B36D4
ROM1:FE11CE8C LDR R0, [R4,#(unk_31B74 - 0x31B5C)]
ROM1:FE11CE90 CMP R0, #0
ROM1:FE11CE94 BNE loc_FE11CEB0
ROM1:FE11CE98 LDRB R1, [R4,#(unk_31B61 - 0x31B5C)]
ROM1:FE11CE9C LDR R0, =unk_FE8CACC8
ROM1:FE11CEA0 BL sub_FE2B3A18
ROM1:FE11CEA4 LDRB R1, [R4,#(unk_31B61 - 0x31B5C)]
ROM1:FE11CEA8 LDR R0, =unk_FE8CAD20
ROM1:FE11CEAC BL sub_FE2B3A18
ROM1:FE11CEB0
ROM1:FE11CEB0 loc_FE11CEB0 ; CODE XREF: PowerSpeakerForWAV+34j
ROM1:FE11CEB0 MOV R0, #1
ROM1:FE11CEB4 STR R0, [R4,#0x2C]
ROM1:FE11CEB8 LDR R0, [R4,#0x48]
ROM1:FE11CEBC LDMFD SP!, {R4,LR}
ROM1:FE11CEC0 B giveSemaphore_ram
ROM1:FE11CEC0 ; End of function PowerSpeakerForWAV
Am I missing a point? can i switch it of somehow? The whole audio stuff is now via serial i would guess..
stefan@morbo-3: ~/Develop/qemu% ./run_canon_fw.sh 1300D,firmware="boot=0" -d debugmsg |& grep SerialCommand_Send
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x1080000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x3960000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x5000000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x7000000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x9030000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xb050000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xf080000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x21010000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xff001b58]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x21020000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xff001b58]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x3960000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x5000000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x7000000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x9030000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xb050000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xf080000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xd010000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xd030000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xd070000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xd0f0000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x55080000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x3b160000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x27130000]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xff004e20]
[ Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x271f0000]
[ AudioCtrl:fe2b3724 ] (14:03) SerialCommand_Send[0x3b160000]
vs. old
stefan@morbo-3: ~/Develop/qemu% ./run_canon_fw.sh 600D,firmware="boot=0" -d debugmsg |& grep 'Reg('
[ Startup:ff06a16c ] (14:03) Reg(0x0D) Data(0x0001)
[ Startup:ff06a16c ] (14:03) Reg(0x0F) Data(0x0000)
[ Startup:ff06a16c ] (14:03) Reg(0x01) Data(0x0008)
[ Startup:ff06a16c ] (14:03) Reg(0x01) Data(0x0008)
[ Startup:ff06a16c ] (14:03) Reg(0x03) Data(0x0096)
[ Startup:ff06a16c ] (14:03) Reg(0x05) Data(0x0000)
[ Startup:ff06a16c ] (14:03) Reg(0x07) Data(0x0000)
[ Startup:ff06a16c ] (14:03) Reg(0x09) Data(0x0003)
[ Startup:ff06a16c ] (14:03) Reg(0x0B) Data(0x0005)
[ Startup:ff06a16c ] (14:03) Reg(0x0F) Data(0x0004)
[ Startup:ff06a16c ] (14:03) Reg(0x0D) Data(0x0003)
[ Startup:ff06a16c ] (14:03) Reg(0x0D) Data(0x000f)
[ Startup:ff06a16c ] (14:03) Reg(0x61) Data(0x000b)
[ Startup:ff06a16c ] (14:03) Reg(0x63) Data(0x000b)
[ Startup:ff06a16c ] (14:03) Reg(0x65) Data(0x0000)
[ Startup:ff06a16c ] (14:03) Reg(0xB1) Data(0x0001)
[ Startup:ff06a16c ] (14:03) Reg(0xB3) Data(0x0008)
[ Startup:ff06a16c ] (14:03) Reg(0xB5) Data(0x0008)
[ Startup:ff06a16c ] (14:03) Reg(0xB7) Data(0x0000)
[ Startup:ff06a16c ] (14:03) Reg(0xB9) Data(0x000b)
[ Startup:ff06a16c ] (14:03) Reg(0xBB) Data(0x0070)
[ Startup:ff06a16c ] (14:03) Reg(0xBD) Data(0x0000)
[ Startup:ff06a16c ] (14:03) Reg(0xBF) Data(0x0001)
[ Startup:ff06a16c ] (14:03) Reg(0xC1) Data(0x0004)
[ Startup:ff06a16c ] (14:03) Reg(0xC3) Data(0x0005)
[ Startup:ff06a16c ] (14:03) Reg(0xC5) Data(0x000d)
[ Startup:ff06a16c ] (14:03) Reg(0xC7) Data(0x0070)
[ Startup:ff06a16c ] (14:03) Reg(0xC9) Data(0x0010)
[ Startup:ff06a16c ] (14:03) Reg(0xCB) Data(0x0000)
[ Startup:ff06a16c ] (14:03) Reg(0x31) Data(0x0002)
[ Startup:ff06a16c ] (14:03) Reg(0x21) Data(0x0001)
[ Startup:ff06a16c ] (14:03) Reg(0x21) Data(0x0002)
[ Startup:ff06a16c ] (14:03) Reg(0x21) Data(0x0006)
[ Startup:ff06a16c ] (14:03) Reg(0x3B) Data(0x001b)
[ Startup:ff06a16c ] (14:03) Reg(0x6B) Data(0x0010)
Yes, there may be different audio chips - the ones we know are listed here: http://magiclantern.wikia.com/wiki/Datasheets
Audio functionality for recent models was not reverse engineered yet (partly because Canon has manual audio controls, unlike on older DIGIC 4). There is the new-sound-system branch which attempts to rewrite the audio side, but last time I've tried it, it was crashing quite often, so it needs some polishing. As I don't really use the audio features, its priority is low from my side (but others are, of course, welcome to look into it).
ok the stubs schould be more or less complete now there is current interupt and task max missing but the rest should be correct. do you know why the propmgr has the assert called?
Yes, answered earlier.
current_interupt should be 0x640 (from the GDB script); task_max should be visible in DryOS info functions in the serial console (mkcfg, objinfo).
ok.. without the PROP_HANDLER( PROP_MVR_REC_START ) the image is booting without errors on qemu .. what should be the next steps?
Quote from: DeinGott on January 18, 2018, 09:35:34 PM
ok.. without the PROP_HANDLER( PROP_MVR_REC_START ) the image is booting without errors on qemu .. what should be the next steps?
Oh dear, things have gotten kind of hung up. I wonder what next steps are, too...
Some ideas:
- find the date of the latest changeset mentioning 1300D
- play with ML menus in QEMU and document which ones fail
- run api_test.lua (http://www.magiclantern.fm/forum/index.php?topic=2864.msg195347;topicseen#msg195347), bench.mo, selftest.mo (some tests will fail in QEMU; document them)
- double-check the stubs (at least one of them is wrong), consts and other model-specific parameters (prefer to be done by other users)
- enable CONFIG_PROP_REQUEST_CHANGE and test the features enabled by this as well (in the emulator, of course)
- look in other recent porting threads; nothing useful?
- proof-read the QEMU guide (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst) (already asked more times than I can count)
- anything else you think you can improve
Has no change been made?
Thanks.
I'm looking forward to see a finished version of ML on this model.
Keep up the good work devs :P
I am ready to test any version of ML on my EOS T6 even though its buggy.
PS: Isn;t T5 similar to the T6 coding?
Quote from: vwdeiu on April 05, 2018, 02:39:13 PM
I am ready to test any version of ML on my EOS T6 even though its buggy.
PS: Isn;t T5 similar to the T6 coding?
My understanding from following this forum post is that the DIGIC 4+ processor in the EOS-1300D/Rebel T6 (and forthcoming 2000D/T7 and 4000D/T100) is mostly a DIGIC 4, with some DIGIC 5 and 6 improvements. So it's not a straight shot from the 1200D/T5 (which used a DIGIC 4 and not a 4+), but it's not completely unfamiliar territory either.
Quote from: Teanut on April 05, 2018, 05:35:45 PM
My understanding from following this forum post is that the DIGIC 4+ processor in the EOS-1300D/Rebel T6 (and forthcoming 2000D/T7 and 4000D/T100) is mostly a DIGIC 4, with some DIGIC 5 and 6 improvements. So it's not a straight shot from the 1200D/T5 (which used a DIGIC 4 and not a 4+), but it's not completely unfamiliar territory either.
Oh.. that means we/re pretty far away from ML on T6 if reverse engeneering isn/t ready yet.
On the contrary - it can be already tested and debugged in QEMU!
When all else fails... read previous posts ;)
For the impatient: QEMU guide (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst), RE guide (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst), installation video for Ubuntu (https://twitter.com/autoexec_bin/status/913530810686418944), for Mac (http://www.magiclantern.fm/forum/index.php?topic=16012.msg191686#msg191686), guide for Windows (http://www.magiclantern.fm/forum/index.php?topic=20214.0) and... next steps (https://www.magiclantern.fm/forum/index.php?topic=17969.msg196303#msg196303).
Quote from: vwdeiu on April 08, 2018, 10:21:09 PM
Oh.. that means we/re pretty far away from ML on T6 if reverse engeneering isn/t ready yet.
See below:Quote from: a1ex on April 09, 2018, 06:57:30 AM
On the contrary - it can be already tested and debugged in QEMU!
When all else fails... read previous posts ;)
For the impatient: QEMU guide (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst), RE guide (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst), installation video for Ubuntu (https://twitter.com/autoexec_bin/status/913530810686418944), for Mac (http://www.magiclantern.fm/forum/index.php?topic=16012.msg191686#msg191686), guide for Windows (http://www.magiclantern.fm/forum/index.php?topic=20214.0) and... next steps (https://www.magiclantern.fm/forum/index.php?topic=17969.msg196303#msg196303).
This thread has a lot of good information if you read the previous posts. I don't have the free time to do a lot of testing right now, but if you do, and want to contribute to ML's progress, give it a shot. It doesn't sound like it's too far off, and I suspect a lot of the hurdles here will also help with the 2000D/T7 and 4000D/T100 (since they're also on DIGIC 4+.) Who knows, maybe it'll even help with DIGIC 6 and above!
Quote from: Teanut on April 09, 2018, 05:28:07 PM
See below:
This thread has a lot of good information if you read the previous posts. I don't have the free time to do a lot of testing right now, but if you do, and want to contribute to ML's progress, give it a shot. It doesn't sound like it's too far off, and I suspect a lot of the hurdles here will also help with the 2000D/T7 and 4000D/T100 (since they're also on DIGIC 4+.) Who knows, maybe it'll even help with DIGIC 6 and above!
Well I'm glad to help...but in terms of coding I dont know anything so if you could tell me the steps I should follow to test the software I'll be gratefull
Quote from: vwdeiu on April 13, 2018, 02:26:47 PM
Well I'm glad to help...but in terms of coding I dont know anything so if you could tell me the steps I should follow to test the software I'll be gratefull
You don't need to know how to code. Look at
a1ex's reply from April 9, 2018 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg199643#msg199643). He already told you the steps. At the bottom he listed links for you to follow on:
- QEMU (the emulation software used for testing) installation instructions for:
- Windows (http://www.magiclantern.fm/forum/index.php?topic=20214.0)
- Mac (http://www.magiclantern.fm/forum/index.php?topic=16012.msg191686#msg191686)
- Ubuntu (https://twitter.com/autoexec_bin/status/913530810686418944)
- How to run Magic Lantern in QEMU (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst)
- The development and reverse engineering guide for ML in QEMU (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst)
- What needs to be done next (https://www.magiclantern.fm/forum/index.php?topic=17969.msg196303#msg196303)
Focus on steps 1, 2, and 4 to start. Document anything that doesn't seem to work right (keep a journal/logbook) by describing what you did and what isn't working correctly, then report it back in this thread. Step 3 seems to require more understanding of code.
Has any progress been made on other DIGIC 4+ cameras yet to try and stir up the pot on the 1300D?
Hate to see this languish, especially when the 4000D is coming, which, while not ideal (no external mic), could help low-budget film makers (e.g. students) who could really benefit from ML.
*bump*
#bringMLto1300D :P :P
What bump?
I am waiting too...
Are you waiting for others to test the software for you, or for others to read the guide for you?
;)
No, I not waiting for others to test for me, or read for me...
How can I test on my camera? Or must test on QEMU?
Result on: make -C ../magic-lantern 1300D_install_qemu :
[ DEPENDS ] mlv_lite.dep
Will NOT load on:
1300D (focus_box_get_raw_crop_offset, get_picstyle_name, raw_lv_redirect_edmac, and 3 others)
[ DEPENDS ] mlv_play.dep
Will NOT load on:
1300D (SetHPTimerNextTick, SetHPTimerAfterNow)
[ DEPENDS ] mlv_rec.dep
Will NOT load on:
1300D (focus_box_get_raw_crop_offset, raw_lv_settings_still_valid, raw_lv_request, and 2 others)
Will NOT load on:
1300D (mlv_rec_get_free_slot, mlv_rec_set_rel_timestamp, mlv_rec_queue_block, and 3 others)
[ DEPENDS ] ettr.dep
Will NOT load on:
1300D (bv_toggle, expo_override_active, bv_auto, expo_lock_update_value)
[ DEPENDS ] silent.dep
Will NOT load on:
1300D (raw_lv_redirect_edmac, raw_lv_request, raw_lv_settings_still_valid, raw_lv_release)
[ DEPENDS ] dot_tune.dep
Will NOT load on:
1300D (get_config_afma_wide_tele, get_afma_mode, set_afma_mode, and 3 others)
[ DEPENDS ] selftest.dep
Will NOT load on:
1300D (SetHPTimerNextTick, bv_toggle, SetHPTimerAfterNow)
[ DEPENDS ] adv_int.dep
Will NOT load on:
1300D (aperture_toggle, iso_toggle, shutter_toggle)
********************************************************
WARNING: module ... failed to build, deleting
********************************************************
What can I do?
For selftest.dep:
[ DEPENDS ] selftest.dep
Will NOT load on:
1300D (SetHPTimerNextTick, bv_toggle, SetHPTimerAfterNow)
I uncomment line:
NSTUB(0xFF06FCE4, SetHPTimerAfterNow)
NSTUB(0xFF06FDD8, SetHPTimerNextTick) in stubs.S and is OK.
The 1300D is still an early port. Perhaps you should start with a minimal build?
cd minimal/1300D
make
Now copy the autoexec.bin file on your bootable card and assuming you got the camera bootflag set it should print "Hello World" on the screen.
Works? Ok--let's try the selftest module.
Commented out stubs probably mean there is some doubt on those addresses. I just did a quick check on them and came up with these values for the 1300D:
NSTUB(0xFE120CEC, SetHPTimerAfterNow)
NSTUB(0xFE120DDC, SetHPTimerNextTick)
That should give you a working selftest module. No guarantees though.
I have test only in qemu, not with my camera.
How can i make bootable card?
My camera don't have bootflag set.
P.S.
I tried to put the HELO1303, HELO1302, HELO1300.fir firmware on my camera, but without success. Start update, then the screen is black. I have to remove the battery because it does not respond at all.
Quote from: critix on May 22, 2018, 02:20:50 PM
How can i make bootable card?
MacBoot (http://www.zenoshrdlu.com/macboot/macboot.html)or EOScard (http://pel.hu/eoscard/)
Quote from: critix on May 22, 2018, 02:20:50 PM
My camera don't have bootflag set.
Can't help you with that. You'll need to ask a1ex.
I can't get QEMU to show the Canon menus, maybe the firmware dump I'm using is invalid?
I make card bootable, I put autoexec.bin, HELO1303.FIR, and i update, but... the same, updating 2-3 sec, black screen... and need out battery... Not working...
Quote
I can't get QEMU to show the Canon menus, maybe the firmware dump I'm using is invalid?
Do you want me to give you the dump from my camera?
Not sure if this is why you can't get the Canon menus up, but if you're just getting a gray screen it's probably because you didn't patch the ROM file like so:
dd if=ROM1.BIN of=BOOT.BIN bs=64K skip=1 count=1
dd if=BOOT.BIN of=ROM1.BIN bs=64K seek=511
@RB13 - Thanks for the tip but it didn't work over here.
Quote from: critix on May 23, 2018, 07:25:43 PM
Do you want me to give you the dump from my camera?
Sure, but we need to do this via PM.
The patched firmware dump from @RB13 is working over here in QEMU but the one from @critix didn't--at least not on my system.
I couldn't get the minimal "Hello World" working but a full ML install does work out of the box:
(https://farm1.staticflickr.com/944/41605196554_81f2f4e928.jpg) (https://flic.kr/p/26ovvr5)
(https://farm1.staticflickr.com/948/41605196694_630f272db7.jpg) (https://flic.kr/p/26ovvtu)
Benchmark module is also working:
(https://farm1.staticflickr.com/893/27458695307_a6f1b20f15.jpg) (https://flic.kr/p/HQqZta)
The suggestion I made on Reply #190 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg201683#msg201683) does seem to get the selftest module working but you also need to enable CONFIG_PROP_REQUEST_CHANGE. Safe to do in QEMU but heed the warning if you plan to run it on your camera:
platform/1300D/internals.h
/** Properties are persistent (saved in NVRAM) => a mistake can cause permanent damage. Undefine this for new ports. */
/** The 1300D port is very early, so I think we should not enable properties. **/
// #undef CONFIG_PROP_REQUEST_CHANGE
#define CONFIG_PROP_REQUEST_CHANGE
As expected the selftest shows several fails in QEMU and even a crash log:
STUBTEST.LOG
[Pass] is_play_mode() => 0x1
[Pass] src = fio_malloc(size) => 0x42204084
[Pass] dst = fio_malloc(size) => 0x42a08090
[Pass] memcmp(dst, src, 4097) => 0xffffff26
[Pass] edmac_memcpy(dst, src, 4097) => 0x42a08090
[Pass] memcmp(dst, src, 4097) => 0x0
[Pass] edmac_memcpy(dst, src, 4097) => 0x42a08090
[Pass] memcmp(dst, src, size) => 0xffffff2d
[Pass] edmac_memcpy(dst, src, size) => 0x42a08090
[Pass] memcmp(dst, src, size) => 0x0
[Pass] memcmp(dst, src, size) => 0x8a
[Pass] edmac_memcpy_start(dst, src, size) => 0x42a08090
dt => 0x0
[Pass] copied => 0x800000
[Pass] copied => 0x800000
[Pass] copied => 0x800000
[Pass] memcmp(dst, src, copied) => 0x0
[FAIL] memcmp(dst, src, copied + 16) => 0x0
edmac_memcpy_finish()
free(src)
free(dst)
Cache test A (EDMAC on BMP buffer)...
[Pass] bmp = bmp_load("ML/CROPMKS/CINESCO2.BMP", 1) => 0x1023b0
[Pass] old => 0x0
[Pass] irq => 0xc0
[FAIL] differences => 0x0
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x0
Cache test B (FIO on 8K buffer)...
[Pass] tries[0] => 0xfe
[Pass] tries[1] => 0xed
[Pass] tries[2] => 0xf3
[Pass] tries[3] => 0x10a
[FAIL] failr[0] => 0x0
[FAIL] failw[0] => 0x0
[FAIL] failr[1] => 0x0
[Pass] failw[1] => 0x0
[Pass] failr[2] => 0x0
[FAIL] failw[2] => 0x0
[Pass] failr[3] => 0x0
[Pass] failw[3] => 0x0
times[0] / tries[0] => 0x4
times[1] / tries[1] => 0x4
times[2] / tries[2] => 0x4
times[3] / tries[3] => 0x4
Cache tests finished.
[Pass] f = FIO_CreateFile("test.dat") => 0x3
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
FIO_CloseFile(f)
[Pass] FIO_GetFileSize("test.dat", &size) => 0x0
[Pass] size => 0x20000
[Pass] p = (void*)_alloc_dma_memory(0x20000) => 0x40bf01a0
[Pass] f = FIO_OpenFile("test.dat", O_RDONLY | O_SYNC) => 0x3
[Pass] FIO_ReadFile(f, p, 0x20000) => 0x20000
FIO_CloseFile(f)
_free_dma_memory(p)
[Pass] count => 0x3a98
[Pass] buf = fio_malloc(0x1000000) => 0x42204084
[FAIL] FIO_GetFileSize_direct("test.dat") => 0xd3f4000
[Pass] f = FIO_OpenFile("test.dat", O_RDWR | O_SYNC) => 0x3
[FAIL] FIO_SeekSkipFile(f, 0, SEEK_END) => 0xd3f4000
[FAIL] FIO_WriteFile(f, buf, 0x10) => 0xffffffff
[FAIL] FIO_SeekSkipFile(f, -0x20, SEEK_END) => 0xd3f3fe0
[FAIL] FIO_WriteFile(f, buf, 0x30) => 0xffffffff
[Pass] FIO_SeekSkipFile(f, 0x20, SEEK_SET) => 0x20
[Pass] FIO_SeekSkipFile(f, 0x30, SEEK_CUR) => 0x50
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_CUR) => 0x30
[FAIL] FIO_GetFileSize_direct("test.dat") => 0xd3f4000
[Pass] is_file("test.dat") => 0x1
[Pass] FIO_RemoveFile("test.dat") => 0x0
[Pass] is_file("test.dat") => 0x0
[Pass] SetTimerAfter(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x5cc4
msleep(900)
[Pass] timer_func => 0x0
msleep(200)
[Pass] timer_func => 0x1
[FAIL] ABS((timer_time/1000 - t0) - 1000) => 0x1b
[Pass] ABS((timer_arg - ta0) - 1000) => 0xa
[Pass] timer = SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x5cca
msleep(400)
CancelTimer(timer)
[Pass] timer_func => 0x0
msleep(1500)
[Pass] timer_func => 0x0
[Pass] SetHPTimerAfterNow(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetHPTimerAfterNow(100000, timer_cbr, overrun_cbr, 0) => 0x330
msleep(90)
[Pass] timer_func => 0x0
msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 100000) => 0x60
[Pass] ABS(DeltaT(timer_arg, ta0) - 100000) => 0x0
[Pass] ABS((get_us_clock_value() - t0) - 110000) => 0xfffff450
[Pass] SetHPTimerAfterNow(90000, next_tick_cbr, overrun_cbr, 0) => 0x332
msleep(80)
[Pass] timer_func => 0x0
msleep(20)
[Pass] timer_func => 0x3
msleep(80)
[Pass] timer_func => 0x3
msleep(20)
[Pass] timer_func => 0x1
[FAIL] ABS(DeltaT(timer_time, t0) - 300000) => 0xae0
[FAIL] ABS(DeltaT(timer_arg, ta0) - 300000) => 0xbb0
[Pass] ABS((get_us_clock_value() - t0) - 310000) => 0xffffdf10
t0 = *(uint32_t*)0xC0242014 => 0xf0d00
msleep(250)
t1 = *(uint32_t*)0xC0242014 => 0x2ae00
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0xd
LoadCalendarFromRTC( &now )
s0 = now.tm_sec => 0x0
Date/time: 2017/09/30 12:15:00
msleep(1500)
LoadCalendarFromRTC( &now )
s1 = now.tm_sec => 0x0
[FAIL] MOD(s1-s0, 60) => 0x0
[Pass] MOD(s1-s0, 60) => 0x0
m0 = MALLOC_FREE_MEMORY => 0x3ee80
[Pass] p = (void*)_malloc(50*1024) => 0x1040f0
[Pass] CACHEABLE(p) => 0x1040f0
m1 = MALLOC_FREE_MEMORY => 0x32670
_free(p)
m2 = MALLOC_FREE_MEMORY => 0x3ee80
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
m0 = GetFreeMemForAllocateMemory() => 0xc7680
[Pass] p = (void*)_AllocateMemory(256*1024) => 0xbf0198
[Pass] CACHEABLE(p) => 0xbf0198
m1 = GetFreeMemForAllocateMemory() => 0x87674
_FreeMemory(p)
m2 = GetFreeMemForAllocateMemory() => 0xc7680
[Pass] ABS((m0-m1) - 256*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
m01 = MALLOC_FREE_MEMORY => 0x3ee80
m02 = GetFreeMemForAllocateMemory() => 0xc7680
[Pass] p = (void*)_alloc_dma_memory(256*1024) => 0x40bf01a0
[Pass] UNCACHEABLE(p) => 0x40bf01a0
[Pass] CACHEABLE(p) => 0xbf01a0
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40bf01a0
_free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(24*1024*1024) => 0x42204074
[Pass] UNCACHEABLE(p) => 0x42204074
_shoot_free(p)
m11 = MALLOC_FREE_MEMORY => 0x3ee80
m12 = GetFreeMemForAllocateMemory() => 0xc7680
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x0
[Pass] suite = shoot_malloc_suite_contig(24*1024*1024) => 0x100e68
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1800000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x100e90
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1800000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42204070
[Pass] UNCACHEABLE(p) => 0x42204070
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite_contig(0) => 0x100e68
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1df8000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x100e90
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1df8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42204070
[Pass] UNCACHEABLE(p) => 0x42204070
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(64*1024*1024) => 0x100e68
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x4
[Pass] suite->size => 0x4000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x100e90
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1df8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42204070
[Pass] UNCACHEABLE(p) => 0x42204070
chunk = GetNextMemoryChunk(suite, chunk) => 0x100ef0
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x257c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x41878064
[Pass] UNCACHEABLE(p) => 0x41878064
chunk = GetNextMemoryChunk(suite, chunk) => 0x100f28
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x2610000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4bf680f4
[Pass] UNCACHEABLE(p) => 0x4bf680f4
chunk = GetNextMemoryChunk(suite, chunk) => 0x100f60
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x4000000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4a000064
[Pass] UNCACHEABLE(p) => 0x4a000064
chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x4000000
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(0) => 0x100e68
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x4
[Pass] suite->size => 0x4300000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x100e90
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1df8000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42204070
[Pass] UNCACHEABLE(p) => 0x42204070
chunk = GetNextMemoryChunk(suite, chunk) => 0x100ef0
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x257c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x41878064
[Pass] UNCACHEABLE(p) => 0x41878064
chunk = GetNextMemoryChunk(suite, chunk) => 0x100f28
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x2610000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4bf680f4
[Pass] UNCACHEABLE(p) => 0x4bf680f4
chunk = GetNextMemoryChunk(suite, chunk) => 0x100f60
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x4300000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4a000064
[Pass] UNCACHEABLE(p) => 0x4a000064
chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x4300000
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x1ad83c
[Pass] msg => 'hi there'
[Pass] snprintf(a, sizeof(a), "foo") => 0x3
[Pass] snprintf(b, sizeof(b), "foo") => 0x3
[Pass] strcmp(a, b) => 0x0
[Pass] snprintf(a, sizeof(a), "bar") => 0x3
[Pass] snprintf(b, sizeof(b), "baz") => 0x3
[Pass] strcmp(a, b) => 0xfffffff8
[Pass] snprintf(a, sizeof(a), "Display") => 0x7
[Pass] snprintf(b, sizeof(b), "Defishing") => 0x9
[Pass] strcmp(a, b) => 0x4
[Pass] snprintf(buf, 3, "%d", 1234) => 0x2
[Pass] buf => '12'
[Pass] memcpy(foo, bar, 6) => 0x1ad820
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x1ad800
[Pass] bar => '*****hjkl;'
bzero32(bar + 5, 5)
[FAIL] bar => '*****'
EngDrvOut(LCD_Palette[0], 0x1234)
[Pass] shamem_read(LCD_Palette[0]) => 0x1234
call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
call("TurnOffDisplay")
[Pass] DISPLAY_IS_ON => 0x0
call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
task_create("test", 0x1c, 0x1000, test_task, 0) => 0xec600c4
[Pass] test_task_created => 0x1
[Pass] get_current_task_name() => 'run_test'
[Pass] task_max => 0x88
[Pass] task_max => 0x88
[Pass] mq = mq ? mq : (void*)msg_queue_create("test", 5) => 0xedc009c
[Pass] msg_queue_post(mq, 0x1234567) => 0x0
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x0
[Pass] m => 0x1234567
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x9
[Pass] sem = sem ? sem : create_named_semaphore("test", 1) => 0xf2e0238
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] take_semaphore(sem, 500) => 0x9
[Pass] give_semaphore(sem) => 0x0
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] give_semaphore(sem) => 0x0
[Pass] rlock = rlock ? rlock : CreateRecursiveLock(0) => 0xf8a00ca
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0xf
CRASH00.LOG
ASSERT: 0
at SystemIF::KerRLock.c:318, run_test:beb8
lv:1 mode:3
run_test stack: 1ad898 [1ad978-1a5978]
0xUNKNOWN @ 41fc:1ad968
0xUNKNOWN @ c850ac:1ad960
0x0000BE28 @ be4bb0:1ad8d8
0x00003CBC @ beb4:1ad8d0
0x00C80378 @ c809b0:1ad898
Magic Lantern version : Nightly.2018May24.1300D110
Mercurial changeset : d10125f654f9+ (1300D)
Built on 2018-05-24 18:15:10 UTC by [email protected].
Free Memory : 223K + 797K
It does not work with my dump because you did not:
Quote from: DeinGott on December 31, 2017, 04:33:23 PM
ok .. i found the problem, why the dump did not run in qemu .. after reading the forum again. i found this post (http://www.magiclantern.fm/forum/index.php?topic=17969.msg172893#msg172893)
dd if=ROM1.BIN of=BOOT.BIN bs=64K skip=1 count=1
dd if=BOOT.BIN of=ROM1.BIN bs=64K seek=511
I sent you the dump extracted from the camera.
Understood -- the thing is, I'm on a Mac so maybe that dd command works a little differently because I couldn't patch it as instructed in Reply #7 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg172893#msg172893).
dd if=ROM1.BIN of=BOOT.BIN bs=64K skip=1 count=1
dd: bs: illegal numeric value
This seems to be the right command on the Mac version of dd but it didn't work in QEMU.
dd if=ROM1.BIN of=BOOT.BIN bs=64000 skip=1 count=1
Quote from: dfort on May 25, 2018, 07:33:15 AM
dd if=ROM1.BIN of=BOOT.BIN bs=64K skip=1 count=1
dd: bs: illegal numeric value
dd if=ROM1.BIN of=BOOT.BIN bs=64000 skip=1 count=1
Equivalent of bs=64K would be bs=65536.
@a1ex
My camera firmware is 1.1.0. Can you give FIR for setting bootflag?
I want bootflag set for my camera for testing magiclantern. I tried HELO1303, HELO1302, HELO1300.fir firmware on my camera, but without success. Start update, then the screen is black. I have to remove the battery because it does not respond at all.
Can you help me?
Thanks a lot...
Quote from: ArcziPL on May 25, 2018, 07:56:18 AM
Equivalent of bs=64K would be bs=65536.
Doh! You are absolutely right.
So for anyone else on a Mac or with an old version of dd, you need to run this on the firmware dump
before running it in QEMU:
dd if=ROM1.BIN of=BOOT.BIN bs=65536 skip=1 count=1
dd if=BOOT.BIN of=ROM1.BIN bs=65536 seek=511
@a1ex: Fir HELO1300-1303 is not for firmware 1.3.3 of camera?
There is no 1.3.3 for this camera. The only firmware updates published by Canon were 1.0.2 and 1.1.0. Development is being done on 1.1.0 (https://bitbucket.org/hudson/magic-lantern/src/1300D/platform/1300D.110/). Reading over previous posts it looks like those ".FIR" files were used to find the firmware signature so they have already served their purpose. Reading through this topic it looks like there is some more that should be done in QEMU before it is "safe" to set the camera boot flag.
Check Reply #173 - Next Steps (https://www.magiclantern.fm/forum/index.php?topic=17969.msg196315#msg196315) for more information.
[EDIT] Running the lua tests is on the list. Some tests won't run in QEMU as documented on this post (https://www.magiclantern.fm/forum/index.php?topic=2864.msg195347#msg195347). In addition, the camera_gui test wouldn't run on the 1300D so there might be a stub that needs fixing. I commented it out and got through most of the tests:
ML/scripts/api_test.lua
...
function api_tests()
menu.close()
console.clear()
console.show()
test_log = logger("LUATEST.LOG")
-- note: each test routine must print a blank line at the end
strict_tests()
generic_tests()
printf("Module tests...\n")
test_io()
-- test_camera_gui()
test_menu()
msleep(1000)
test_multitasking()
test_camera_exposure()
printf("Done!\n")
test_log:close()
key.wait()
console.hide()
end
...
The problem I ran into was that the "A" key would not switch to Av mode so the test ends there:
LUATEST.LOG
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2017-9-30 12:15:00
===============================================================================
Strict mode tests...
Strict mode tests passed.
Generic tests...
arg = table:
[0] = "API_TEST.LUA"
camera = table:
shutter = table:
raw = 104
apex = 6.
ms = 16
value = 0.015625
aperture = table:
raw = 83
apex = 9.375
value = 25.7
min = table:
raw = 40
apex = 4.
value = 4.
max = table:
raw = 83
apex = 9.375
value = 25.7
iso = table:
raw = 0
apex = 0
value = 0
ec = table:
raw = 0
value = 0
flash_ec = table:
raw = 0
value = 0
kelvin = 4700
mode = 3
metering_mode = 3
drive_mode = 0
model = "Canon EOS 1300D"
model_short = "1300D"
firmware = "1.1.0"
temperature = 152
gui = table:
menu = false
play = false
play_photo = false
play_movie = false
qr = false
idle = true
wait = function: p
bulb = function: p
burst = function: p
reboot = function: p
shoot = function: p
event = table:
pre_shoot = nil
post_shoot = nil
shoot_task = nil
seconds_clock = nil
keypress = nil
custom_picture_taking = nil
intervalometer = nil
config_save = nil
console = table:
hide = function: p
show = function: p
write = function: p
clear = function: p
lv = table:
enabled = false
paused = false
running = false
zoom = 1
overlays = false
start = function: p
resume = function: p
stop = function: p
wait = function: p
info = function: p
pause = function: p
lens = table:
name = "EF-S18-55mm f/3.5-5.6 IS"
focal_length = 0
focus_distance = 14080
hyperfocal = 0
dof_near = 0
dof_far = 0
af = false
af_mode = 3
autofocus = function: p
focus = function: p
display = table:
idle = nil
height = 480
width = 720
line = function: p
off = function: p
load = function: p
screenshot = function: p
clear = function: p
on = function: p
rect = function: p
circle = function: p
print = function: p
notify_box = function: p
pixel = function: p
draw = function: p
key = table:
last = 10
wait = function: p
press = function: p
menu = table:
visible = false
select = function: p
get = function: p
new = function: p
block = function: p
close = function: p
set = function: p
open = function: p
movie = table:
recording = false
start = function: p
stop = function: p
dryos = table:
clock = 3
ms_clock = 3550
image_prefix = "IMG_"
dcim_dir = table:
exists = true
create = function: p
children = function: p
files = function: p
parent = table:
exists = true
create = function: p
children = function: p
files = function: p
parent = table:
exists = true
create = function: p
children = function: p
files = function: p
parent = nil
path = "B:/"
path = "B:/DCIM/"
path = "B:/DCIM/100CANON/"
config_dir = table:
exists = true
create = function: p
children = function: p
files = function: p
parent = table:
exists = true
create = function: p
children = function: p
files = function: p
parent = table:
exists = true
create = function: p
children = function: p
files = function: p
parent = nil
path = "B:/"
path = "ML/"
path = "ML/SETTINGS/"
ml_card = table:
cluster_size = 16384
drive_letter = "B"
file_number = 8700
folder_number = 100
free_space = 216896
type = "SD"
_card_ptr = userdata
path = "B:/"
shooting_card = table:
cluster_size = 16384
drive_letter = "B"
file_number = 8700
folder_number = 100
free_space = 216896
type = "SD"
_card_ptr = userdata
path = "B:/"
date = table:
wday = 2
day = 30
month = 9
sec = 0
min = 15
isdst = false
year = 2017
hour = 12
yday = 1
rename = function: p
remove = function: p
directory = function: p
call = function: p
interval = table:
time = 10
count = 0
running = false
stop = function: p
battery = table:
function not available on this camera
stack traceback:
[C]: in ?
[C]: in for iterator 'for iterator'
ML/SCRIPTS/LIB/logger.lua:125: in function 'logger.serialize'
ML/SCRIPTS/API_TEST.LUA:36: in function <ML/SCRIPTS/API_TEST.LUA:35>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:35: in function 'print_table'
ML/SCRIPTS/API_TEST.LUA:81: in function 'generic_tests'
ML/SCRIPTS/API_TEST.LUA:1338: in function 'api_tests'
ML/SCRIPTS/API_TEST.LUA:1359: in main chunktask = table:
create = function: p
yield = function: p
property = table:
Generic tests completed.
Module tests...
Testing file I/O...
Copy test: autoexec.bin -> tmp.bin
Copy test OK
Append test: tmp.txt
Append test OK
Rename test: apple.txt -> banana.txt
Rename test OK
Rename test: apple.txt -> ML/banana.txt
Rename test OK
File I/O tests completed.
Testing ML menu API...
Menu tests completed.
Testing multitasking...
Only one task allowed to interrupt...
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Main task yielding.
Task C started.
Task C finished.
Main task back.
Multitasking tests completed.
Testing exposure settings...
Camera : Canon EOS 1300D (1300D) 1.1.0
Lens : EF-S18-55mm f/3.5-5.6 IS
Shoot mode: 3
Shutter : Ç60 (raw 104, 0.015625s, 16ms, apex 6.)
Aperture : Å25 (raw 83, f/25.7, apex 9.375)
Av range : Å4.0..Å25 (raw 40..83, f/4...f/25.7, apex 4...9.375)
ISO : 1600 (raw 104, 1600, apex 9.)
EC : 0.0 (raw 0, 0 EV)
Flash EC : 0.0 (raw 0, 0 EV)
Setting shutter to random values...
Setting ISO to random values...
Setting aperture to random values...
Please switch to Av mode.
Ok I understand. But seeing DeinGott as he tested the camera in this https://www.magiclantern.fm/forum/index.php?topic=17969.msg195984#msg195984 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg195984#msg195984), I thought I could set the flag to test myself on the camera.
For:
battery = table:
function not available on this camera
stack traceback:
[C]: in ?
[C]: in for iterator 'for iterator'
ML/SCRIPTS/LIB/logger.lua:125: in function 'logger.serialize'
ML/SCRIPTS/API_TEST.LUA:36: in function <ML/SCRIPTS/API_TEST.LUA:35>
[C]: in function 'xpcall'
ML/SCRIPTS/API_TEST.LUA:35: in function 'print_table'
ML/SCRIPTS/API_TEST.LUA:81: in function 'generic_tests'
ML/SCRIPTS/API_TEST.LUA:1338: in function 'api_tests'
ML/SCRIPTS/API_TEST.LUA:1359: in main chunktask = table:
just comment line in
function generic_tests()
-- print_table("battery")
If you search for "battery = table:" on this forum you'll find this is common with most cameras. The battery table test will continue even if it encounters an error.
Running only test_camera_gui() will not complete and the lua script will come to a screeching halt.
(https://farm2.staticflickr.com/1749/28489652058_87105ccd88.jpg) (https://flic.kr/p/KpwUZy)
===============================================================================
ML/SCRIPTS/API_TEST.LUA - 2017-9-30 12:15:00
===============================================================================
Module tests...
Testing Canon GUI functions...
However, I tried the same test on the 1200D in QEMU and got the same results so maybe test_camera_gui() can't be done in QEMU?
It does seem to me that we are close to testing ML on the 1300D but that's not my call. Besides, I don't have access to one of these cameras.
Quote from: a1ex on January 24, 2018, 09:18:42 AM
- double-check the stubs (at least one of them is wrong), consts and other model-specific parameters (prefer to be done by other users)
I was able to find the missing GUI timers stubs but I'm going on vacation tomorrow for about three weeks so I won't have time to double-check all of the stubs. At least not for a while. It isn't difficult, it just takes time. This is the first Digic 4+ camera being ported and it seems to share characteristics of both Digic 4 and 5. I'd suggest comparing the 1300D stubs with the 1200D and other (somewhat) similar cameras.
I saw that the complete test was not done ...
I've found some "new" stubs:
GUI_SetLvMode -> 0xFE2EB7F8
SetSamplingRate - > 0xFE11C6A8 - Now it is 0xFE11C690
ChangeHDMIOutputSizeToFULLHD -> 0xFE48A9C0
ChangeHDMIOutputSizeToVGA -> 0xFE48AC84
GUI_GetFirmVersion -> 0xFE2F3BA8
FSUunMountDevic -> 0xFE41C994
EnableImagePhysicalScreenParameter -> 0xFE2A75D4
GUI_GetCFnForTab4 -> 0xFE4716F0
StartPlayProtectGuideApp -> 0xFE5E91B4
StopPlayProtectGuideApp -> 0xFE5E8E04
ptpPropSetUILock -> 0xFE1FDBE8
print_serial -> 0xFE0180A8
I do not know if it helps with anything or not in development ...
Thanks.
@critix - That helps. Could you do a pull request for the new stubs? That way you'll get credit for the find and it makes it easier to track the changes.
How can do that? :)
Here's a simple way to do it with just a web browser:
Submitting a pull request all via web browser (https://www.magiclantern.fm/forum/index.php?topic=7940.msg70958#msg70958)
If you are using Mercurial (hg) you can make the edits on the 1300D branch of your Magic Lantern fork, commit the changes and do a pull request on bitbucket. There are plenty of posts and tutorials on how to do pull requests.
Look over the current pull requests and the merged pull requests to see how it is done.
https://bitbucket.org/hudson/magic-lantern/pull-requests/?state=MERGED
Done.
I made requests for the new Stubs...
199 files changed for just a few stubs?
https://bitbucket.org/hudson/magic-lantern/pull-requests/928/1300d-new-stubs/diff
Sorry, I was wrong with Pull requests.
P.S. It's OK now?
@critix -- your new pull request looks much better. I'm running around on vacation for another couple of weeks but will try it out on QEMU when I get home.
Hello
I am a beginner in the Magic Lantern and I own a Canon 1300d. My question would be whether you already had something working or at least an orientation to the installation? I am willing to help, taking into account that I do not have the basics to develop something. I'm from Brazil and I'm really looking forward to the launch for my Canon.
@a1ex -- Would it be possible to get a ML-SETUP.FIR for this camera or are there still some issues that need to be resolved first?
Will check; I'm also catching up after holidays.
edit: replied on bitbucket (https://bitbucket.org/hudson/magic-lantern/pull-requests/929/add-new-stubs-value/diff#comment-68167794).
Been doing some private stub hunting coaching with @critix -- private because we've been looking at disassembled Canon code. The pull request (https://bitbucket.org/hudson/magic-lantern/pull-requests/929/add-new-stubs-value/diff) he is working on will need to be redone so I thought some of the notes that came up should be discussed on this forum topic.
Quote from: a1exFirst thing obviously wrong: bzero32.
How's this?
platform/1300D.110/stubs.S
NSTUB( 0x29898, bzero32) // called by cstart() rom
This seems to be working fine in QEMU though I'm not really sure what to look for.
Quote from: a1exSecond thing obviously wrong: task list doesn't work; is_taskid_valid has a different syntax (address is correct). This one could have been noticed within minutes of playing with QEMU; don't remember anyone mentioning it.
I've been playing with QEMU but again not sure what to look for. Here's a snippet from a QEMU session and it looks to me that tasks are starting up fine:
[****] Starting task fe2be514(7d7940) TOMgr
[ TOMgr:fe123c94 ] (00:01) [PM] DisablePowerSave (Counter = 2)
[ TOMgr:fe37e258 ] (43:05) tomSetRawJpgMode (Type = 0x4)
[ TOMgr:fe123d04 ] (00:01) [PM] EnablePowerSave (Counter = 1)
[****] Starting task fe2be514(7da6fc) Fstorage
[****] Starting task fe2be514(7d754c) ShootPreDevelop
[ShootPreDevelop:fe134a38 ] (95:05) spsInit
[****] Starting task fe12b9c0(0) AEmodeJudge
[****] Starting task fe5423d8(0) CSMgrTask
55: 110.080 [RSC] hMemoryQue[MPU] Sending : 1a 18 01 4e 00 00 00 00 00 00 00 00 00 00 00 1e 00 00 00 0f 00 00 00 00 00 00 (PROP_VIDEO_MODE)
[ DbgMgr:fe123c94 ] (00:01) [PM] DisablePowerSave (Counter = 2)
[ DbgMgr:fe123d04 ] (00:01) [PM] EnablePowerSave (Counter = 1)
ue (0x660012) hStorageQueue (0x680014)
117: 115.456 [RTC] PROPAD_GetPropertyData : PROP_RTC 0xfd
120: 117.504 [RTC] ChangePropertyCBR 0x0, 0x0
121: 117.760 [RTC] RTC_Permit 0x20
135: 118.784 [SND] Seq LPC fin
153: 119.808 [ENG] [ENGIO](Addr:0x4fb40000, Data:0x 30000)
167: 122.880 [TERMINATE] SHUTDOWN init comp
169: 122.880 [TERMINATE] Abort init comp
176: 128.256 [WB] AdjustWb Done.
196: 130.048 [MC] PROP_GUI_STATE 0
201: 130.048 [MC] JobState 0
204: 130.304 [MC] PROP_LCD_OFFON_BUTTON : 0
206: 130.304 [MC] PROP_VARIANGLE_GUICTRL : Enable
209: 130.816 [MC] regist master CardCover
Modules are loading:
Register modules...
Load configs...
Init modules...
[i] Init: 'lua'
[ module_task:00c002bc ] task_create(lua_load_task, prio=1c, stack=10000, entry=c01a60, arg=0)
[****] Starting task c01a60(0) lua_load_task
[i] cbr 'CBR_PRE_SHOOT' -> 000C021D8
[i] cbr 'CBR_POST_SHOOT' -> 000C021A4
[i] cbr 'CBR_SHOOT_TASK' -> 000C02170
[i] cbr 'CBR_SECONDS_CLOCK' -> 000C0213C
[i] cbr 'CBR_KEYPRESS' -> 000C0209C
[i] cbr 'CBR_CUSTOM_PICTURE_TAKING' -> 000C02068
[i] cbr 'CBR_INTERVALOMETER' -> 000C02030
[i] cbr 'CBR_CONFIG_SAVE' -> 000C01FFC
Updating symbols...
[i] 404: edmac_format_size c81930
[i] 404: edmac_format_size c83a50
[i] 404: edmac_format_size c8d230
[i] 404: edmac_format_size c8eba0
[i] 404: dual_iso_get_recovery_iso c97b10
[i] 404: dual_iso_is_active c97b10
[i] 404: auto_ettr_intervalometer_wait ca41b0
[i] 404: auto_ettr_intervalometer_warning ca41b0
[i] 404: auto_ettr_export_correction caaca0
[i] 404: dual_iso_get_dr_improvement cb85d0
[i] 404: dual_iso_get_recovery_iso cb85d0
[i] 404: edmac_format_size cbc250
And the GUI is looking good:
(https://farm1.staticflickr.com/847/41263593870_e27f290bda_n.jpg) (https://flic.kr/p/25SjGRC)
(https://farm2.staticflickr.com/1762/41263593760_1764d93038_n.jpg) (https://flic.kr/p/25SjGPJ)
Several modules aren't building but that's also a problem with the 1100D (shameless plug for my pull request (https://bitbucket.org/hudson/magic-lantern/pull-requests/925/1100d-unified-updates/diff))
(https://farm1.staticflickr.com/842/42355700394_7a39ccc66b_n.jpg) (https://flic.kr/p/27wQ35s)
Quote from: a1exA few more: FOCUS_CONFIRMATION 0x36EC4, HALFSHUTTER_PRESSED 0x359BC, INFO_BTN_NAME "DISP" and I could go on.
I'm confused. This is what is in the current code:
platform/1300D.110/consts.h [EDIT] originally pasted the 1200D values, these are from the 1300D
// guess
#define FOCUS_CONFIRMATION (*(int*)0x479C)
#define HALFSHUTTER_PRESSED (*(int*)0x31308) // same as 60D
Finding stubs using pattern matching won't help with these and I'm not sure how to use QEMU to ferret them out.
Quote from: a1exI was hoping to find somebody who understands how a computer works, to some extent...
Not me--I went to art school 8)
FOCUS_CONFIRMATION and HALFSHUTTER_PRESSED were copied from 1200D and not updated. The former was covered here (https://www.magiclantern.fm/forum/index.php?topic=18966.msg180212#msg180212) and the latter around here (https://www.magiclantern.fm/forum/index.php?topic=15895.msg186670#msg186670).
Tasks: Debug menu. They start (task_create is correct), but you cannot get much info about them. The stubs are correct, but the syntax is not; maybe it's better to enumerate them by walking the internal DryOS structure; hopefully that's a bit more portable. So far, offsets for task name and ID were the same on DIGIC 4 until 7 (even the Eeko secondary core, which runs a very lightweight firmware, uses the same DryOS task structure). I'd expect the tasks to be stored in a linked list, and the next/prev pointers are likely at the same offset on all DryOS models.
bzero32 looks fine now.
Quote from: a1ex on June 28, 2018, 10:09:40 PM
FOCUS_CONFIRMATION and HALFSHUTTER_PRESSED were copied from 1200D and not updated.
Sorry, I pasted the wrong values on my previous post (corrected). The 1200D and 1300D values
are different. 1200D
// From Alex
#define FOCUS_CONFIRMATION (*(int*)0x3EA8) // a1ex
#define HALFSHUTTER_PRESSED (*(int*)0x2A28) // used for Trap Focus and Magic Off.
1300D
// guess
#define FOCUS_CONFIRMATION (*(int*)0x479C)
#define HALFSHUTTER_PRESSED (*(int*)0x31308) // same as 60D
This gives me something to chew on:
Quote from: nikfreak on July 01, 2017, 08:16:47 PM
#define HALFSHUTTER_PRESSED (*(int*)0x24884) is ok [0x2486C+0x18].
When searching through the disassembly for a pattern there are instances where the value that we're looking for needs to be offset. Why? I don't know, maybe it is a structure (http://magiclantern.wikia.com/wiki/Struct_Guessing)?
I search for HIJACK_INSTR_BL_CSTART and a found this value: 0xFE0C062C
1200D:
loc_ff0c0190:
ff0c0190: e1500003 cmp r0, r3
ff0c0194: 34802004 strcc r2, [r0], #4
ff0c0198: 3afffffc bcc loc_ff0c0190
ff0c019c: eb0003a1 bl loc_ff0c1028 <--- value of cstart
1300D
loc_fe0c062c:
fe0c062c: e1500003 cmp r0, r3
fe0c0630: 34802004 strcc r2, [r0], #4
fe0c0634: 3afffffc bcc loc_fe0c062c
fe0c0638: ea000cf9 b loc_fe0c3a24 <--- value of cstart
I also looked for:
#define HIJACK_INSTR_BSS_END FE0C3B10ok
define HIJACK_FIXBR_BZERO32 FE0C3A58
#define HIJACK_FIXBR_CREATE_ITASK FE0C3AF8
#define HIJACK_INSTR_MY_ITASK FE0C3B20
but the values seem to be good.
Is OK?
I don't understand why you say that the value you found is 0xFE0C062C. The current value of 0xFE0C0638 matches what is in the 1200D.
What do you think of this one?
#define HIJACK_INSTR_BSS_END 0xFE0C3B14
These constants are tough to find using just pattern matching. Maybe there's a better way using QEMU? I don't have access to IDA Pro and wouldn't know how to use it if I did!
I have disassembled with arm_console, and I searched through 60D values for FOCUS_CONFIRMATION and HALFSHUTTER_PRESSED.
I found the value given by dfort for HALFSHUTTER_PRESSED -> 0x31308.
For FOCUS_CONFIRMATION I found 0x4680.
Is ok this value?
Thanks.
How did you find those values--pattern matching? I found the same by pattern matching but searching for the same pattern on the 1200D resulted in completely different values than what was found to work on that camera. So my guess is that the values that you found are probably not ok.
On Reply #220 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg203278#msg203278) a1ex provided some links that if you follow will lead you a wiki article on Struct Guessing (http://magiclantern.wikia.com/wiki/Struct_Guessing). It uses the FOCUS_CONFIRMATION stub as an example. I checked the example against the 550D.109, 60D.111 and 1200D.102 and they all have a structure that looks something like this:
(FOCUS STRUCTURE ADDRESS) + 0x4 = FOCUS_CONFIRMATION
So the value we need to search for is 0x4 less than the value of the FOCUS_CONFIRMATION stub that was found for the camera you're using to pattern match to.
After working through the article my guess is this:
1300D
#define FOCUS_CONFIRMATION (*(int*)0x5C7D1)
Assuming that the FOCUS STRUCTURE ADDRESS = 0x5C7CD
Look up this string in the disassemblies and the pattern to match is a few lines down from there.
" focusstatus %x,%x":
[EDIT] On second look maybe a better guess would be this?
1300D
#define FOCUS_CONFIRMATION (*(int*)0x36EC4)
Assuming that the FOCUS STRUCTURE ADDRESS = 0x36EC0
The 1300D is somewhat different from the other cameras we're using as references so it is a bit tricky to find the right lines that match up.
Data structures placed at odd addresses are quite rare in the ARM world. The CPU used by these cameras (DIGIC 5 and earlier) cannot even read 32-bit integers from unaligned addresses. That's a warning flag.
From that page, you are looking for something read from memory, at offset 4 within some data structure, and compared to 1. That is:
FE166C90 LDR R0, [R5,#4]
FE166C94 CMP R0, #1
Then you need to find the address of that data structure, right before the above lines. That address is in R5, not R0.
Whether that actually does what we expect (i.e. becoming TRUE when focus is confirmed, even in MF mode), remains to be seen. On 700D, 650D, 100D and EOS M, apparently it doesn't.
Quote from: a1ex on July 07, 2018, 10:02:32 PM
That address is in R5, not R0.
Right--I edited my post after I realized that but maybe you didn't see the update when you made your post.
fe166c78: ldr r5, [pc, #-996] ; fe16689c: (00036ec0)
So we should be on the right track here:
1300D
#define FOCUS_CONFIRMATION (*(int*)0x36EC4)Quote from: a1ex on July 07, 2018, 10:02:32 PM
Whether that actually does what we expect (i.e. becoming TRUE when focus is confirmed, even in MF mode), remains to be seen. On 700D, 650D, 100D and EOS M, apparently it doesn't.
Does it work on the 1200D? That's what we (critix and I) are mainly using because it seems to be the closest match to the 1300D. Of course that camera is also fairly early in the development stages. However, if we look at that same section of code (near focusstatus %x,%x) on the cameras you say focus confirmation isn't working, we come up with some different values.
Camera | current value | possible change? |
700D | 0x24884 | 0x27660 |
650D | 0x24878 | 0x275A0 |
EOSM | 0x3F224 | 0x420F0 |
I couldn't find it on the 100D using this method but I didn't try very hard.
So how to confirm focus confirmation is confirming? Is there a test for it? Maybe a simple lua script will do the trick?
[EDIT] Is this why trap focus isn't working on these cameras?
Trap focus was reported to work on 1200D, outside LiveView. I've tried to cover this (FOCUS_CONFIRMATION) in selftest.mo and api_test.lua, but on 700D & co., the focus apparently gets confirmed only during AF; so the tests were passing IIRC, but trap focus was still not working. Not sure how to debug this - maybe capturing a log with MPU messages during confirmation and see what happens in QEMU. This address was found with a very old tool called mem_spy, that shows memory addresses that change as you try stuff on the camera.
I compiled the mem_spy module and activated it. I started qemu and I run the selftest module, and get the error below:
Quote[MPU] Received: 08 06 04 0c 03 00 00 00 (PROP_SHOOTING_TYPE - spell #72)
[MPU] Sending : 08 06 04 0c 03 00 01 00 (PROP_SHOOTING_TYPE)
[MPU] Received: 06 05 03 34 00 00 (PROP_Q_POSITION - spell #45)
[MPU] Received: 08 06 00 00 04 00 00 00 (Complete WaitID = 0x80020000 - spell #48)
[MPU] Received: 06 04 04 13 00 00 (unknown - PROP 80020012)
[MPU] Received: 08 06 00 00 04 0c 00 00 (unknown - Complete WaitID)
[MPU] Received: 06 04 09 00 00 00 (unknown - PROP_LV_LENS)
[MPU] Received: 06 05 09 0b 02 00 (unknown - PROP_LV_AF_RESULT)
6614: 24839.936 [MC] PROP_GUI_STATE 0
6741: 24843.008 WARN [LVDS] First Get DTS_GetAllRandomData
6750: 24843.264 [LV] [PATH] GetPathDriveInfo[0]
6756: 24843.264 WARN [LVDS] First Get DTS_GetAllRandomData
6758: 24843.520 WARN [LVDS] First Get DTS_GetAllRandomData
6782: 24843.776 WARN [LVDS] First Get DTS_GetAllRandomData
6784: 24843.776 WARN [LVDS] First Get DTS_GetAllRandomData
6800: 24861.952 [CAPD] ERROR Image Power Failure
6801: 24861.952 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x82218001 => 0x8221800
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #75)
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #75)
6811: 24909.568 [MC] cam event guimode comp. 0
6823: 24916.480 [GUI] ERROR ***** Lv GetMovieFrameRateIcon S (81)
Do you know why?
Thanks
Hi.
After searches, I found the following values:
File consts.h:
#define HIJACK_INSTR_BSS_END 0xFE0C3B14
#define MVR_992_STRUCT (*(void**)(0x315dc+0x4)) // look in MVR_Initialize for AllocateMemory call
#define IMGPLAY_ZOOM_POS_X MEM(0x6FCC4) // Look up *"CentrePos x:%ld y:%ld"
#define IMGPLAY_ZOOM_POS_Y MEM(0x6FCC8) // (0x6FCC4+0x4) Look up *"CentrePos x:%ld y:%ld"
#define VIDEO_PARAMETERS_SRC_3 0x6A95C
#define DISPLAY_SENSOR_POWERED (*(int*)(0x359a0 + 0x18)) // =0x359B8; Look up *"ForceDisableDisplay (%d)"
#define INFO_BTN_NAME "DISP" // like 1200D
#define HALFSHUTTER_PRESSED (*(int*)0x359BC) // look for string "[MC] permit LV instant"
#define FOCUS_CONFIRMATION (*(int*)0x36EC4) // (0x36EC0 + 0x4) see "focusinfo" and Wiki:Struct_Guessing
In file fps-engio.c is OK this value?
#elif defined(CONFIG_1300D)
#define NEW_FPS_METHOD 1
#define SENSOR_TIMING_TABLE MEM(0x4015C)
#define VIDEO_PARAMETERS_SRC_3 0x6A95C
#define TG_FREQ_BASE 28800000
#undef FPS_TIMER_A_MIN
#define FPS_TIMER_A_MIN (ZOOM ? 734 : MV1080 ? 546 :576)
#undef FPS_TIMER_B_MIN
#define FPS_TIMER_B_MIN (ZOOM ? 1312 : MV480 ? 2000 : MV720 ? 1000 : 2200)
When I run:
./run_canon_fw.sh 1300D,firmware="boot=1" -s -S & arm-none-eabi-gdb -x 1300D/debugmsg.gdb
I got this error:
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #75)
1328: 825.344 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown MovieInfo
1329: 825.344 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
1347: 760.320 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown MovieInfo
1348: 760.320 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
1353: 760.576 [MC] cam event guimode comp. 0
[ DisplayMgr:fe123f78 ] register_interrupt(null, 0x34, 0xfe123e10, 0x1)
1408: 802.560 [DISP] TurnOnDisplay action Type=0
[ DisplayMgr:fe123f78 ] register_interrupt(null, 0x34, 0xfe123e10, 0x1)
[ DisplayMgr:fe123f78 ] register_interrupt(null, 0x34, 0xfe123e10, 0x1)
Why? How can i fixed?
Quote from: critix on July 11, 2018, 11:55:59 AM
In file fps-engio.c is OK this value?
I think that the timer values need to be found on the actual hardware.
As far as the QEMU error messages, I'm getting that too. Not sure if this is anything significant that needs to be worked out before trying out a minimal build on the camera.
Why I get this error:
1348: 510.976 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown Mo[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #75)
vieInfo
1349: 510.976 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
1367: 511.232 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown MovieInfo
1368: 511.232 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
1373: 511.232 [MC] cam event guimode comp. 0
1411: 551.680 [DISP] TurnOnDisplay action Type=0
even I run ./run_canon_fw.sh 1300D,firmware="boot=0".
After the qemu starts, the video menu never appears. Not even if I run ./run_canon_fw.sh 1300D,firmware="boot=1"
Quote from: critix on July 16, 2018, 10:45:20 AM
After the qemu starts, the video menu never appears.
Probably because the firmware was dumped with the camera in Photo mode.
There is a way to switch over to Movie mode but it requires having a startup log made with the camera in Movie mode then running the extract_init_spells.py script in qemu-eos/qemu-2.5.0/hw/eos/mpu_spells. This will create a 1300D.h file that when placed in the mpu_spells directory will allow QEMU to start the emulation in a different mode. More about this in this post (https://www.magiclantern.fm/forum/index.php?topic=2864.msg193132#msg193132) in the "How to run Magic Lantern into QEMU?!... " topic.
If you create a new firmware dump with the camera in Movie mode and run the new dump in QEMU it should show the video menu--after patching the dump as explained by a1ex in Reply #7 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg172893#msg172893).
Note that there might be a way to switch between Photo and Movie modes in QEMU but I'm not sure if that is possible on the 1300D and if so which buttons you need to press.
On 1300D, the movie mode is on the mode dial. If you press F1 during emulation:
[MPU] Available keys:
...
- 0/9 : Mode dial (press only)
- V : Movie mode (press only)
...
Movie mode is 20:
#define SHOOTMODE_MOVIE 0x14
If the emulation starts in M mode (3), you should press the "0" key 17 times. Or, just press V. After that, press Q to show the LiveView menu, but the image capture is not emulated.
Then, it will lock up when trying to change the resolution; probably some incorrect MPU message for PROP_VIDEO_MODE. We'll fix that after getting some logs from the camera.
Didn't manage to double-check the latest constants yet; will prepare a FIR after that.
Lots of buttons to press to get to the movie menus but much easier than making a new firmware dump or running extract_init_spells.py on a startup log.
(https://farm1.staticflickr.com/847/41637449830_54f8c6975a.jpg) (https://flic.kr/p/26rmPd3)
I have tried dm-spy-experiments branch merged in my 1300D branch. OK., but when I run ./run_canon_fw.sh 1300D,firmware="boot=1" I got this error when enable DebugMsg Log:
[MPU] Received: 06 05 03 19 00 00 (PROP_TFT_STATUS - spell #41)
Save configs...
ICache: 8192b, idx=7e0 tag=fffff800 word=1c seg=c0000000
Jump range error: cf2e60 -> fe2993b8 != 22993b8
Patch error at fe2993b4 (jump out of range) = cf2e60
Jump range error: cf2e60 -> fe10fa74 != 210fa74
Patch error at fe10fa70 (jump out of range) = cf2e60
What are wrong?
This one is hard to fix - branch instructions in ARM code cannot go "too far" (they are limited to +/- 32MB around the address of the branch instruction). Normally, the compiler takes care of this (e.g. by using long jumps or inserting veneers - intermediate jumps), but here we are patching existing binary code in the firmware, to jump to our code instead.
I couldn't find an easy fix for this one; while a long jump can be implemented, it may require patching 2 instructions for one function. It's doable though, and other cameras will benefit from this (60D, which has the same problem in some experimental branches, and maybe some newer models too).
On 1300D I'm afraid we can't just use the workaround for 60D (where we load ML at a different address in order to be able to patch things), so a proper fix will be required in order to get some useful debug logs.
Thank you. Then I will not continue with dm-spy-experiments branch.
Until you can create the FIR file, what could I do?
I run ./run_canon_fw.sh 1300D,firmware="boot=1" for dm-spy-experiments and I get crash in Debug -> Free Memory:
ASSERT: 0
at SystemIF::KerTask.c:191, guess_mem:39b0
lv:0 mode:3
guess_mem stack: 1a98a8 [1a9978-1a5978]
0xUNKNOWN @ 41fc:1a9968
0x00C8F0A8 @ c81ca8:1a9920
0xUNKNOWN @ c8f0f0:1a9908
0x000038FC @ c82158:1a98f8
0x00003CBC @ 39ac:1a98e0
0x00C8036C @ c808d8:1a98a8
Magic Lantern version : Nightly.2018Jul17.1300D110
Mercurial changeset : c289baed76d1+9dff88575e96+ (1300D)
Built on 2018-07-17 16:33:24 UTC by root@DESKTOP-7QS9FV7.
Free Memory : 247K + 586K
In CLI I have:
[DM] FROM Write Complete!!!
ASSERT : SystemIF::KerTask.c, Task = guess_mem, Line 191
ASSERT : SystemIF::KerTask.c, Task = guess_mem, Line 191
ASSERT : SystemIF::KerTask.c, Task = guess_mem, Line 191
Maybe that it helps...
Quote from: dfort on July 15, 2018, 08:40:23 PM
I think that the timer values need to be found on the actual hardware.
How can i found the timer values? Must magiclantern run on real camera?
Hi! I know nothing about programing, how can I install ML to my Rebel T6?
On Rebel T6 is not working yet...
I have found some values in the const.h file, which are found at 1200D and 550D, but which at 1300D did not appear.
// Used in boot-hack.c with CONFIG_ALLOCATE_MEMORY_POOL
#define ROM_ITASK_START 0xFE1296C8
#define ROM_ITASK_END 0xFE129768
#define ROM_CREATETASK_MAIN_START 0xFE0C1B60
#define ROM_CREATETASK_MAIN_END 0xFE0C1EB0
#define ROM_ALLOCMEM_END 0xFE0C1B74
#define ROM_ALLOCMEM_INIT 0xFE0C1B7C
#define ROM_B_CREATETASK_MAIN 0xFE129760
#define ARMLIB_OVERFLOWING_BUFFER 0x310a8 // in AJ_armlib_setup_related3
These values have also been checked by dfort.
But... when make install_qemu I have error:
make[1]: Leaving directory '/home/cristi/magic-lantern-1300D/tcc'
[ CC ] module.o
[ AR ] strrchr.o
[ AR ] dietlibc.a
[ AR ] lib_a-setjmp.o
[ AR ] newlib-libc.a
[ CP ] newlib-libm.a
[ CP ] gcc-libgcc.a
[ LD ] magiclantern
boot-hack.o: In function `init_task_patched':
/home/cristi/magic-lantern-1300D/platform/1300D.110/../../src/boot-hack.c:606: undefined reference to `reloc'
/home/cristi/magic-lantern-1300D/platform/1300D.110/../../src/boot-hack.c:614: undefined reference to `reloc'
../../src/Makefile.src:197: recipe for target 'magiclantern' failed
make: *** [magiclantern] Error 1
Are not the values found good?
Hint:
platform/1300D.110/consts.h
// Used in boot-hack.c with CONFIG_ALLOCATE_MEMORY_POOL
Now look here:
platform/1300D.110/internals.h
/** This camera loads ML into the AllocateMemory pool **/
//#define CONFIG_ALLOCATE_MEMORY_POOL
Notice that it is commented out on the 1300D and active on the 1200D and 550D. Can the 1300D use CONFIG_ALLOCATE_MEMORY_POOL? I don't know the answer to that but you can try it out in QEMU.
Yes, i uncomment this line but i get error :
[ CP ] gcc-libgcc.a
[ LD ] magiclantern
boot-hack.o: In function `init_task_patched':
/home/cristi/magic-lantern-1300D/platform/1300D.110/../../src/boot-hack.c:606: undefined reference to `reloc'
/home/cristi/magic-lantern-1300D/platform/1300D.110/../../src/boot-hack.c:614: undefined reference to `reloc'
../../src/Makefile.src:197: recipe for target 'magiclantern' failed
make: *** [magiclantern] Error 1
Right, remembering what we did on the EOSM2 there's a lot more to getting CONFIG_ALLOCATE_MEMORY_POOL working. For now I'd recommend commenting out those constants like on the 50D.
I have modified the compute_signature type from uint32_t to int.
In file reboot.c from:
uint32_t s = compute_signature((void*)SIG_START, SIG_LEN);
uint32_t expected_signature = CURRENT_CAMERA_SIGNATURE;
if (s != expected_signature)
{
qprint("[boot] firmware signature: "); qprintn(s); qprint("\n");
qprint(" expected: "); qprintn(expected_signature); qprint("\n");
to:
int s = compute_signature((int*)SIG_START, SIG_LEN);
int _signature = (int)CURRENT_CAMERA_SIGNATURE;
if (s != _signature)
{
qprint("[boot] firmware signature: "); qprintn(s); qprint("\n");
qprint(" expected: "); qprintn(_signature); qprint("\n");
And in the file fw-signature.h from:
static uint32_t compute_signature(uint32_t * start, uint32_t num)
{
uint32_t c = 0;
for (uint32_t * p = start; p < start + num; p++)
to:
static int compute_signature(int* start, int num)
{
int c = 0;
int* p;
for (p = start; p < start + num; p++)
I compile minimally
make -C ../magic-lantern-1300D/minimal/1300D/ install_qemu
then run
./run_canon_fw.sh 1300D, firmware="boot=1"
but I get the following error:
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x7EA0
Now jump to AUTOEXEC.BIN!!
008073EC: MCR p15, ... : CACHEMAINT x770 (omitted)
008073EC: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
000BF634: MCR p15, ... : CACHEMAINT x257 (omitted)
000BF634: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
DRYOS PANIC: Module Code = 1, Panic Code = 2
[MPU] WARNING: forced shutdown.
Without making the above changes, I could not compile minimally, I received the error:
[ CC ] reboot.o
../../src/reboot.c:207:12: error: conflicting types for 'compute_signature'
extern int compute_signature(int* start, int num);
^
In file included from ../../src/reboot.c:29:0:
../../src/fw-signature.h:37:17: note: previous definition of 'compute_signature' was here
static uint32_t compute_signature(uint32_t * start, uint32_t num)
^
../../Makefile.filerules:25: recipe for target 'reboot.o' failed
make: *** [reboot.o] Error 1
How to fix the error:
DRYOS PANIC: Module Code = 1, Panic Code = 2
I run:./run_canon_fw.sh 1300D,firmware="boot=1" -d calls
I get:
0x000052b4: eafff28f b 0x1cf8
call 0x1E4C(0, 0, 0, 305c0 "\nCopyright (C) 1997-2014 by CANON Inc.\n") at [1cfc:c373c]
call 0xFE0C0F48(1, 2, 0, 31170 current_task) at [1e88:1d00]
call 0xFE0C0A50(1, 2, 0, 31170 current_task) at [fe0c0f54:1e8c]
return 1 to 0xFE0C0F58 at [fe0c0a5c:1e8c]
call 0x262C(fe0c1070 "DRYOS PANIC: Module Code = %d, Panic Code = %d\n", 1, 2, 31170 current_task)
at [fe0c0f80:1e8c]
call 0x66B8(fe0c0a04, 0, fe0c1070 "DRYOS PANIC: Module Code = %d, Panic Code = %d\n", fcc)
at [2650:fe0c0f84]
call 0xFE0C0A04(0, fe0c1070 "DRYOS PANIC: Module Code = %d, Panic Code = %d\n", 1b, fe0c0a04)
at [6718:2654]
jump to 0xFE0C3B6C lr=671c at [fe0c0a24:671c]
0xfe0c0a24: ea000c50 b 0xfe0c3b6c
call 0xFE1292E0(0, fe0c1070 "DRYOS PANIC: Module Code = %d, Panic Code = %d\n", 1b, f38)
at [fe0c3b80:671c]
DRYOS PANIC: Module Code = return 0 to 0xFE0C3B84 at [fe129364:671c]
return 1b to 0x671C at [fe0c3b90:2654]
call 0x6BAC(fe0c108c "d, Panic Code = %d\n", f8c, ffffffff, 1b) at [6730:2654]
return fe0c108c to 0x6734 at [6c30:2654]
call 0x5AE0(fe0c108c "d, Panic Code = %d\n", f88, 0, 1b) at [6748:2654]
return fe0c108c to 0x674C at [5b30:2654]
call 0x6C3C(f6c, 0, 1, 0) at [69d8:2654]
Tried running a minimal build from the vanilla "hudson" repository and came up with the same error:
./run_canon_fw.sh 1300D,firmware="boot=1" -d debugmsg
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x15A0
Now jump to AUTOEXEC.BIN!!
DRYOS PANIC: Module Code = 1, Panic Code = 2
Quote from: a1ex on June 25, 2017, 05:16:06 PM
That's a good sign - this message can only appear from the main firmware, so we are no longer in bootloader context. Still, probably something went wrong when patching the startup process.
Ok--we've been here before with the EOSM2 but in this case a full ML build is working on the 1300D but a minimal build isn't.
@a1ex -- any hints?
Yeah, discussed this on IRC with critix some days ago. The issue appears with the classic boot process, while reserving memory for ML. Unfortunately, this is not possible with current minimal startup code if we just adjust the constants. This code is also used for the installer and some other "minimal" experiments. I should find a way to refactor that code, as DIGIC 2, 3, 6, 7 and very likely 8 are also affected.
In the DryOS shell (QEMU window: View -> Serial0), type "akashimorino", then "drysh", then "meminfo -m". You'll get:
K404[1]>drysh
Dry> meminfo -m
Malloc Information (onetime type)
Start Address = 0x000bf408
End Address = 0x00141ac8
Total Size = 0x000826c0 ( 534208)
Allocated Size = 0x0002fac8 ( 195272)
Allocated Peak = 0x0002fb28 ( 195368)
Allocated Count = 0x00000055 ( 85)
Free Size = 0x00052bf8 ( 338936)
Free Block Max Size = 0x00052b98 ( 338840)
Free Block Count = 0x00000002 ( 2)
What does that mean?
This is the heap used by Canon firmware for malloc. It's quite small, i.e. not large enough for loading the full ML; that's why we use AllocateMemory for that on cameras with a small "malloc" heap. However, for mission-critical stuff (like setting the boot flag, which is going to modify the ROM) I prefer this minimalist "one size fits all" code, which so far worked on all DIGIC 4 and 5 cameras. 1300D is the first exception.
Why?
0xFE0C3A60 LDR R0, =0x14B400
0xFE0C3A6C SUB R1, R0, #0x8C000 ; result is 0xbf400
These two are the start (R1) and end (R0) address of our malloc heap. We want to resize (shrink) it and load autoexec.bin there. This trick is to make sure Canon firmware is not going to overwrite our code.
On all other DIGIC 4 and 5 models, these two addresses are loaded from a PC-relative address, i.e. with LDR instructions. Therefore, we define HIJACK_INSTR_BSS_END*) to point to that constant, and we change its value in the relocated startup code according to autoexec.bin size. If we load ML at the beginning of that heap, we have RESTARTSTART set slightly above 0xbf400, and we modify the start address of that heap to be above our BSS (that is, after the last memory address our autoexec.bin is going to use for statically allocated things).
*) I have a feeling the BSS_END name actually comes from this:
Dry> memmap
== DRAM ==
00001900 : data start
0x0004dbac(318380)
0004f4ac : bss start
0x000358d0(219344)
000bf400 : heap start <-- see Trammell's comment: "Reserve memory after the BSS for our application"
0x000828ec(534764)
00141cec : heap end
Anyway. The amount of memory we take away from Canon's malloc heap is, from 80D's minimal.c:
uint32_t ml_reserved_mem = (uintptr_t) _bss_end - INSTR( HIJACK_INSTR_BSS_END );
On 1300D, to change the start address, we no longer a constant that we can just modify in the relocated startup code; it's an instruction that we have to change. Some ways to fix:
- allocate space for this constant (e.g. somewhere in the _reloc buffer) and replace that SUB instruction with a LDR
- replace that SUB instruction with a MOV (e.g. MOV R1, #new_address)
- change the end address instead (that won't help, as we'd have to recompute that SUB so the start address stays the same)
- load the minimal binary elsewhere, e.g. there's a 0.88MB gap (https://www.magiclantern.fm/forum/index.php?topic=5071.msg186876#msg186876) apparently unused (however, I wouldn't trust it for mission-critical code, as the 60D also has apparently unused regions in that graph that are actually used by Canon firmware).
Option #2 appears to be fairly straightforward, except we need a way to encode arbitrary values in a MOV instructions. We've got a bunch of definitions in arm-mcr.h:
#define MOV_R0_0x450000_INSTR 0xE3A00845
#define MOV_R1_0xC80000_INSTR 0xE3A01732
#define MOV_R1_0xC60000_INSTR 0xE3A018C6
However, the constant I want to encode depends on autoexec.bin size (that would be the address of _bss_end, rounded up). Therefore, I'd like a generic definition that would encode some arbitrary constant as a MOV instruction. Back then, Nanomad tried to provide such a definition, but it's currently incomplete:
#define MOV_RD_IMM_INSTR(rd,imm)\
( 0xE3A00000 \
| (rd << 15) \
)
So, that's a small low-level coding task I've suggested to critix, but anyone else is welcome to give it a try.
Quote from: a1ex on August 05, 2018, 06:12:41 PM
I should find a way to refactor that code, as DIGIC 2, 3, 6, 7 and very likely 8 are also affected.
Hopefully done (https://bitbucket.org/hudson/magic-lantern/commits/a39719e958bc327e72132a0936f3caff412d3731); I could finally compile the installer and other minimal examples!
cd minimal/hello-world
make MODEL=1300D clean
make MODEL=1300D install_qemu CONFIG_QEMU=y
Yay!
(https://farm2.staticflickr.com/1819/30297274438_feb4f62880_z.jpg) (https://flic.kr/p/Nags9E)
Does this mean that a .FIR file is near?
Superb ... That means we are a big step forward.
Congratulations...
I can hardly wait to start the 1300D magic-lantern.
Quote from: dfort on August 21, 2018, 12:54:41 AM
Yay!
Fantastic, indeed! I tried duplicating the process without much luck...
cbbrowne@cbbrowne2:~/GitStuff/magic-lantern/minimal/hello-world$ ls
Makefile minimal.c
cbbrowne@cbbrowne2:~/GitStuff/magic-lantern/minimal/hello-world$ make MODEL=1300D clean
../../platform/Makefile.platform.base:19: FW_VERSION for 1300D is not defined
../../platform/Makefile.platform.base:60: *** ROMBASEADDR is not defined. Stop.
But if others are moving forwards, tis awesome!
Minimal it's work. I tested like dfort and i's work.
Hi, long time thread lurker, first time poster. I was wondering how things were coming along with getting ML to run on the 1300D? It seems like some significant progress has been made last but there hasn't been a new post in almost a month now.
Minimal should be working on camera but the boot flag needs to be enabled. Compiling a ML-SETUP.FIR for the 1300D is pretty much up to a1ex's discretion at this point.
Hello I am new and I saw a friend used ML but it is a 5D and I have the 1300D, my kind question is whether the full or workable version for the 1300D is already available and where you can download it, thanks.
Quote from: a1ex on August 20, 2018, 09:53:25 PM
Hopefully done (https://bitbucket.org/hudson/magic-lantern/commits/a39719e958bc327e72132a0936f3caff412d3731); I could finally compile the installer and other minimal examples!
cd minimal/hello-world
make MODEL=1300D clean
make MODEL=1300D install_qemu CONFIG_QEMU=y
I am also curious as how this port is coming along?
https://wiki.magiclantern.fm/faq#any_progress_on_xyz
hey... I don't wanna be one of those guys, but I've been checking this thread every other day for like a year... every bump gives me hope
Money time what is needed to finish the T6 ML?
Money isn't an issue. Work is done by devs in their spare time (if any).
Time might be, though. But only if one requirement is met:
Top of page -> Downloads -> Download nightly builds -> Your camera is not listed?
"A port of a new camera model happens if and only if there is a developer who has the camera and sufficient time, motivation and skill to complete the port."
Camera is rather old but entry level. Porting ML onto it should be straight forward once you've already done a port. I several times was thinking about doing EOS 2000D port but would never invest or buy that cam on my own. It's identical to the EOS 1300D. Even the sdcard is still crippled and will only do 20MB/s (forget raw video!!!) but it has 24Mpx sensor which got my interest (https://www.dxomark.com/canon-eos-2000d-sensor-review-step-1300d/) (seems to be on par with 750D). So would be useful for stills photography.
Quote from: Walter Schulz on November 01, 2018, 08:06:18 AM
Money isn't an issue. Work is done by devs in their spare time (if any).
Time might be, though. But only if one requirement is met:
Top of page -> Downloads -> Download nightly builds -> Your camera is not listed?
"A port of a new camera model happens if and only if there is a developer who has the camera and sufficient time, motivation and skill to complete the port."
Looks like it is an issue over here on Twitter... lol
https://twitter.com/RandumAccess/status/1055627275406843904?s=20
Hi long time thread lurker. I'm just wondering is their anything i could do to help?
I don't mean for this come off as an ad but maybe some of the people on here still waiting for ML to get ported over to the 1300D, should check out an app called DslrController. The things I was most interested in ML were focus peaking, crop marks and zebras and this app makes your phone or tablet act like an external monitor that offers up those options. It can be quite laggy when recording but you get used to it and I find that it's a decent alternative to ML.
Hey guys. Full stack principal dev here. I have this camera and I want to help. No idea where to start. What do I need and what can I do to help? I really want ML on the EOS Rebel T6. Been monitoring the thread for a long time and I have no idea where to start. I don't know of any wiki that has a getting started thing and I can't seem to glean WTF is going on from any of the random posts I read. Are there other areas on this forum that are generic enough to get started with something???
@stealthkk
Another long time lurker here who hasn't had the time to contribute.
In answer to your question, as far as I can make out, at the top of this forum page there is a link for Downloads. From there is a Source Code section with links to download the source code and a compiler.
There is also a link to Browse the Source Code. From there is a Branches link from where you will get to the select and view the 1300D commit history and code.
There is also a General Development Discussion (https://www.magiclantern.fm/forum/index.php?board=25.0) forum.
Hi.
Alex, can you generate Magic Lantern State Diagrams for 1300D?
Thanks.
Quote from: jox58 on December 08, 2018, 06:01:45 AM
@stealthkk
Another long time lurker here who hasn't had the time to contribute.
In answer to your question, as far as I can make out, at the top of this forum page there is a link for Downloads. From there is a Source Code section with links to download the source code and a compiler.
There is also a link to Browse the Source Code. From there is a Branches link from where you will get to the select and view the 1300D commit history and code.
There is also a General Development Discussion (https://www.magiclantern.fm/forum/index.php?board=25.0) forum.
Soooooo.....yyyeah, I was going to clone source and begin helping today but to my surprise the repo is in Mercurial.... ummmmm... ooookay. Interesting choice. Unfortunately I, and most of the development world, use git so I guess I'll have to get Mercurial and learn it. Slight setback.
Maybe this helps?
https://bitbucket.org/durin42/hg-git/src/default/
In any case, using Mercurial probably isn't the hard part. Dump the firmware, patch it to run in QEMU, disassemble it and find the missing pieces.
I have defined CONFIG_PROP_REQUEST_CHANGE in internals.h.
I left only the following active modules for compilation:
file_man \
lua \
bench \
selftest \
adv_int \
edmac \
If I set the lines in all_features.h:
#ifdef CONFIG_PROP_REQUEST_CHANGE
#define FEATURE_LV_ZOOM_SETTINGS
#define FEATURE_LV_ZOOM_SHARP_CONTRAST
#ifdef CONFIG_EXPSIM
#define FEATURE_LV_ZOOM_AUTO_EXPOSURE
#endif
//~ #define FEATURE_ZOOM_TRICK_5D3 // not reliable
#define FEATURE_LV_FOCUS_BOX_FAST
#define FEATURE_LV_FOCUS_BOX_SNAP
//~ #define FEATURE_LV_FOCUS_BOX_SNAP_TO_X5_RAW
#define FEATURE_LV_FOCUS_BOX_AUTOHIDE
....
#endif
everything is compiled without errors, but once I start qemu, it blocks itself to:
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xC80480
Cache patch: [FE0C3B20] <- C80480 (was FE1296C8)
00C803F4: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
Lockdown read 1
00C803F8: MRC p15,3,Rd,cr15,cr1,0: IcacheTag -> 0x0
00C803A8: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE92D4010
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x364
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE24DD018
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x368
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE28F0F9A
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x36C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEBFFFDB5
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x370
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB015F55
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0160D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x378
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0082D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x37C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB01961C
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A018C8
Cache patch: [FE0C1B74] <- E3A018C8 (was E3A0160D)
If those definitions are commented, then it's ok.
I'm trying to run Hello Word from script with definition commented but crash:
ASSERT: 0
at SystemIF::KerQueue.c:522, GuiMainTask:7860
lv:0 mode:3
GuiMainTask stack: 19d878 [19d948-19b948]
0x02426B7C @ 23b4240:19d8b8
0x00003CBC @ 785c:19d8b0
0x00C80378 @ c80804:19d878
Magic Lantern version : Nightly.2019Jan13.1300D110
Mercurial changeset : 788eff4f6400+ (1300D)
Built on 2019-01-13 10:17:22 UTC by root@cristi.
Free Memory : 256K + 622K
Why is it blocking the patch cache?
OK.
I've made some updates:
https://bitbucket.org/ccritix/magic-lantern/commits/32716ee6e3114f4f497443512be313c96e706026
I also made a PR:
https://bitbucket.org/hudson/magic-lantern/pull-requests/951
I ran Stubs API Test and the result is as follows:
[Pass] is_play_mode() => 0x1
[INFO] Camera model: Canon EOS 1300D 1.1.0 (0x80000404 1300D)
[Pass] is_camera("DIGIC", "*") => 0x1
[Pass] is_camera(__camera_model_short, firmware_version) => 0x1
[Pass] src = fio_malloc(size) => 0x4256c114
[Pass] dst = fio_malloc(size) => 0x42d70120
[Pass] memcmp(dst, src, 4097) => 0xffffff26
[Pass] edmac_memcpy(dst, src, 4097) => 0x42d70120
[Pass] memcmp(dst, src, 4097) => 0x0
[Pass] edmac_memcpy(dst, src, 4097) => 0x42d70120
[Pass] memcmp(dst, src, size) => 0xffffff6c
[Pass] edmac_memcpy(dst, src, size) => 0x42d70120
[Pass] memcmp(dst, src, size) => 0x0
[Pass] memcmp(dst, src, size) => 0x78
[Pass] edmac_memcpy_start(dst, src, size) => 0x42d70120
dt => 0x0
[Pass] copied => 0x800000
[Pass] copied => 0x800000
[Pass] copied => 0x800000
[Pass] memcmp(dst, src, copied) => 0x0
[FAIL] memcmp(dst, src, copied + 16) => 0x0
edmac_memcpy_finish()
free(src)
free(dst)
Cache test A (EDMAC on BMP buffer)...
[Pass] bmp = bmp_load("ML/CROPMKS/CINESCO2.BMP", 1) => 0xa105d0
[Pass] old => 0x0
[Pass] irq => 0xc0
[FAIL] differences => 0x0
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x0
Cache test B (FIO on 8K buffer)...
[Pass] tries[0] => 0x101
[Pass] tries[1] => 0x104
[Pass] tries[2] => 0xdf
[Pass] tries[3] => 0x104
[FAIL] failr[0] => 0x0
[FAIL] failw[0] => 0x0
[FAIL] failr[1] => 0x0
[Pass] failw[1] => 0x0
[Pass] failr[2] => 0x0
[FAIL] failw[2] => 0x0
[Pass] failr[3] => 0x0
[Pass] failw[3] => 0x0
times[0] / tries[0] => 0x4
times[1] / tries[1] => 0x4
times[2] / tries[2] => 0x4
times[3] / tries[3] => 0x4
Cache tests finished.
[Pass] f = FIO_CreateFile("test.dat") => 0x3
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
FIO_CloseFile(f)
[Pass] FIO_GetFileSize("test.dat", &size) => 0x0
[Pass] size => 0x20000
[Pass] p = (void*)_alloc_dma_memory(0x20000) => 0x40bd6da0
[Pass] f = FIO_OpenFile("test.dat", O_RDONLY | O_SYNC) => 0x3
[Pass] FIO_ReadFile(f, p, 0x20000) => 0x20000
FIO_CloseFile(f)
_free_dma_memory(p)
[Pass] count => 0x3a98
[Pass] buf = fio_malloc(0x1000000) => 0x4256c114
[FAIL] FIO_GetFileSize_direct("test.dat") => 0xd39c000
[Pass] f = FIO_OpenFile("test.dat", O_RDWR | O_SYNC) => 0x3
[FAIL] FIO_SeekSkipFile(f, 0, SEEK_END) => 0xd39c000
[FAIL] FIO_WriteFile(f, buf, 0x10) => 0xffffffff
[FAIL] FIO_SeekSkipFile(f, -0x20, SEEK_END) => 0xd39bfe0
[FAIL] FIO_WriteFile(f, buf, 0x30) => 0xffffffff
[Pass] FIO_SeekSkipFile(f, 0x20, SEEK_SET) => 0x20
[Pass] FIO_SeekSkipFile(f, 0x30, SEEK_CUR) => 0x50
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_CUR) => 0x30
[FAIL] FIO_GetFileSize_direct("test.dat") => 0xd39c000
[Pass] is_file("test.dat") => 0x1
[Pass] FIO_RemoveFile("test.dat") => 0x0
[Pass] is_file("test.dat") => 0x0
[Pass] SetTimerAfter(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x5fe2
msleep(900)
[Pass] timer_func => 0x0
msleep(200)
[Pass] timer_func => 0x1
[Pass] ABS((timer_time/1000 - t0) - 1000) => 0xd
[Pass] ABS((timer_arg - ta0) - 1000) => 0xa
[Pass] timer = SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x5ff0
msleep(400)
CancelTimer(timer)
[Pass] timer_func => 0x0
msleep(1500)
[Pass] timer_func => 0x0
[Pass] SetHPTimerAfterNow(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetHPTimerAfterNow(100000, timer_cbr, overrun_cbr, 0) => 0x3fc
msleep(90)
[Pass] timer_func => 0x0
msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 100000) => 0x60
[Pass] ABS(DeltaT(timer_arg, ta0) - 100000) => 0x0
[Pass] ABS((get_us_clock() - t0) - 110000) => 0xfffff450
[Pass] SetHPTimerAfterNow(90000, next_tick_cbr, overrun_cbr, 0) => 0x3fe
msleep(80)
[Pass] timer_func => 0x0
msleep(20)
[Pass] timer_func => 0x3
msleep(80)
[Pass] timer_func => 0x3
msleep(20)
[Pass] timer_func => 0x1
[FAIL] ABS(DeltaT(timer_time, t0) - 300000) => 0x9e0
[FAIL] ABS(DeltaT(timer_arg, ta0) - 300000) => 0xab0
[Pass] ABS((get_us_clock() - t0) - 310000) => 0xffffdf10
t0 = GET_DIGIC_TIMER() => 0x82f00
msleep(250)
t1 = GET_DIGIC_TIMER() => 0xbd400
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0xc
LoadCalendarFromRTC( &now )
s0 = now.tm_sec => 0x0
Date/time: 2017/09/30 15:15:00
msleep(1500)
LoadCalendarFromRTC( &now )
s1 = now.tm_sec => 0x0
[FAIL] MOD(s1-s0, 60) => 0x0
[Pass] MOD(s1-s0, 60) => 0x0
m0 = MALLOC_FREE_MEMORY => 0x3f0e0
[Pass] p = (void*)_malloc(50*1024) => 0x103938
[Pass] CACHEABLE(p) => 0x103938
m1 = MALLOC_FREE_MEMORY => 0x328d0
_free(p)
m2 = MALLOC_FREE_MEMORY => 0x3f0e0
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
m0 = GetFreeMemForAllocateMemory() => 0x989e0
[Pass] p = (void*)_AllocateMemory(128*1024) => 0xbd6d90
[Pass] CACHEABLE(p) => 0xbd6d90
m1 = GetFreeMemForAllocateMemory() => 0x789d4
_FreeMemory(p)
m2 = GetFreeMemForAllocateMemory() => 0x989e0
[Pass] ABS((m0-m1) - 128*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
m01 = MALLOC_FREE_MEMORY => 0x3f0e0
m02 = GetFreeMemForAllocateMemory() => 0x989e0
[Pass] p = (void*)_alloc_dma_memory(128*1024) => 0x40bd6da0
[Pass] UNCACHEABLE(p) => 0x40bd6da0
[Pass] CACHEABLE(p) => 0xbd6da0
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40bd6da0
_free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(16*1024*1024) => 0x4256c104
[Pass] UNCACHEABLE(p) => 0x4256c104
_shoot_free(p)
m11 = MALLOC_FREE_MEMORY => 0x3f0e0
m12 = GetFreeMemForAllocateMemory() => 0x989e0
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x0
[Pass] suite = shoot_malloc_suite_contig(16*1024*1024) => 0x100a10
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x100a38
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1000000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4256c100
[Pass] UNCACHEABLE(p) => 0x4256c100
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite_contig(0) => 0x100a10
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1f68000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x100a38
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1f68000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4a000064
[Pass] UNCACHEABLE(p) => 0x4a000064
largest_shoot_block = suite->size => 0x1f68000
[INFO] largest_shoot_block: 31MB
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(largest_shoot_block + 1024*1024) => 0x100a10
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x3
[Pass] suite->size => 0x2068000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x100a38
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1a90000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4256c100
[Pass] UNCACHEABLE(p) => 0x4256c100
chunk = GetNextMemoryChunk(suite, chunk) => 0x100a98
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1d18000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42100064
[Pass] UNCACHEABLE(p) => 0x42100064
chunk = GetNextMemoryChunk(suite, chunk) => 0x100ad0
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x2068000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x41878064
[Pass] UNCACHEABLE(p) => 0x41878064
chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x2068000
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(0) => 0x100a10
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x4
[Pass] suite->size => 0x4300000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x100a38
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1a90000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4256c100
[Pass] UNCACHEABLE(p) => 0x4256c100
chunk = GetNextMemoryChunk(suite, chunk) => 0x100a98
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1d18000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42100064
[Pass] UNCACHEABLE(p) => 0x42100064
chunk = GetNextMemoryChunk(suite, chunk) => 0x100ad0
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x3c80000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4a000064
[Pass] UNCACHEABLE(p) => 0x4a000064
chunk = GetNextMemoryChunk(suite, chunk) => 0x100b08
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x4300000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x41878064
[Pass] UNCACHEABLE(p) => 0x41878064
chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x4300000
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x1ad834
[Pass] msg => 'hi there'
[Pass] snprintf(a, sizeof(a), "foo") => 0x3
[Pass] snprintf(b, sizeof(b), "foo") => 0x3
[Pass] strcmp(a, b) => 0x0
[Pass] snprintf(a, sizeof(a), "bar") => 0x3
[Pass] snprintf(b, sizeof(b), "baz") => 0x3
[Pass] strcmp(a, b) => 0xfffffff8
[Pass] snprintf(a, sizeof(a), "Display") => 0x7
[Pass] snprintf(b, sizeof(b), "Defishing") => 0x9
[Pass] strcmp(a, b) => 0x4
[Pass] snprintf(buf, 3, "%d", 1234) => 0x2
[Pass] buf => '12'
[Pass] memcpy(foo, bar, 6) => 0x1ad800
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x1ad7e0
[Pass] bar => '*****hjkl;'
bzero32(bar + 5, 5)
[FAIL] bar => '*****'
EngDrvOut(LCD_Palette[0], 0x1234)
[Pass] shamem_read(LCD_Palette[0]) => 0x1234
call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
call("TurnOffDisplay")
[Pass] DISPLAY_IS_ON => 0x0
call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
task_create("test", 0x1c, 0x1000, test_task, 0) => 0x29d000ca
[Pass] test_task_created => 0x1
[Pass] get_current_task_name() => 'run_test'
[FAIL] get_task_name_from_id(current_task->taskId) => '?'
[Pass] task_max => 0x88
[Pass] task_max => 0x88
[Pass] mq = mq ? mq : (void*)msg_queue_create("test", 5) => 0x29d200b8
[Pass] msg_queue_post(mq, 0x1234567) => 0x0
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x0
[Pass] m => 0x1234567
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x9
[Pass] sem = sem ? sem : create_named_semaphore("test", 1) => 0x29d401d2
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] take_semaphore(sem, 500) => 0x9
[Pass] give_semaphore(sem) => 0x0
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] give_semaphore(sem) => 0x0
[Pass] rlock = rlock ? rlock : CreateRecursiveLock(0) => 0x29d600ec
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0xf
SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x1
SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x2
SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x0
[FAIL] display_idle() => 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[Pass] PLAY_MODE => 0x1
[Pass] MENU_MODE => 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000);
[Pass] MENU_MODE => 0x1
[Pass] PLAY_MODE => 0x0
[Pass] dialog->type => 'DIALOG'
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[Pass] PLAY_MODE => 0x0
SW1(1,100)
[FAIL] HALFSHUTTER_PRESSED => 0x0
SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[FAIL] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
=========================================================
Test complete, 11501 passed, 21 failed.
.
I ran Memory Benchmarks and the result:
(https://i.ibb.co/M5GNCTX/img1.jpg) (https://ibb.co/M5GNCTX)
From the all_features.h file I commented on the following lines because with them active qemu is blocked as in the above post:
#define FEATURE_EXPO_APERTURE
#define FEATURE_EXPO_LOCK
#define FEATURE_EXPO_PRESET
#define FEATURE_HDR_BRACKETING
#define FEATURE_FOLLOW_FOCUS
#define FEATURE_RACK_FOCUS
#define FEATURE_FOCUS_STACKING
#define FEATURE_LV_ZOOM_SETTINGS
#define FEATURE_LV_ZOOM_SHARP_CONTRAST
#define FEATURE_LV_ZOOM_AUTO_EXPOSURE
#define FEATURE_LV_FOCUS_BOX_FAST
#define FEATURE_LV_FOCUS_BOX_SNAP
#define FEATURE_POWERSAVE_LIVEVIEW
I'm going to see what I'm with those statements.
At this time, the modules are also compiled, less:
adv_int
ettr
dot_tune
Quote from: critix on January 13, 2019, 11:32:06 AM
I'm trying to run Hello Word from script with definition commented but crash:
Hello World from your PR branch is working over here.
(https://farm8.staticflickr.com/7807/32873898518_cdb46d5b5b.jpg) (https://flic.kr/p/S5XjHL)
I can't get into the ML menus on a vanilla build but I'm also having a problem with the EOSM2 so it could be my setup. Looks like you're already running tests and creating logs -- nice progress!
Yes, I did not specify this, but Hello World is running smoothly.
I have tried to compile the adtg_gui module and the trace module. I set up
CONFIG_GDB = y
CONFIG_GDBSTUB = y
It compiles ok, but when run qemu remains stuck at the line:
Cache patch: [FE0C1B74] <- E3A018C8 (was E3A0160D)
I still can not figure out why it is blocking on that line.
./run_canon_fw.sh 1300D,firmware=boot=1 -d debugmsg &
DebugMsg=0xFE11F394 (from GDB script)
Lockdown read 1
Lockdown read 1
Lockdown read 0
Lockdown read 0
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
Lockdown read 5
Lockdown read 5
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: eos.ram_uncached
F0000000 - F1FFFFFF: eos.rom0
F2000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F9FFFFFF: eos.rom1
FA000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.mmio
[EOS] enabling code execution logging.
[EOS] loading './1300D/ROM0.BIN' to 0xF0000000-0xF1FFFFFF
[EOS] mirrored data; unique 0x10 bytes repeated 0x200000 times
[EOS] loading './1300D/ROM1.BIN' to 0xF8000000-0xF9FFFFFF
[MPU] warning: non-empty spell #11 (PROP_CARD2_STATUS) has duplicate(s): #52
[MPU] warning: non-empty spell #20 (PROP_TFT_STATUS) has duplicate(s): #37 #38 #75
[MPU] warning: non-empty spell #35 (PROP_VIDEO_MODE) has duplicate(s): #36
[MPU] warning: non-empty spell #43 (PROP_TFT_STATUS) has duplicate(s): #41 #42 #44 #46
[MPU] Available keys:
- Arrow keys : Navigation
- [ and ] : Main dial (top scrollwheel)
- SPACE : SET
- DELETE : guess (press only)
- M : MENU (press only)
- P : PLAY (press only)
- I : INFO/DISP (press only)
- Q : guess (press only)
- L : LiveView (press only)
- A : Av
- Z/X : Zoom in/out
- Shift : Half-shutter
- 0/9 : Mode dial (press only)
- V : Movie mode (press only)
- B : Open battery door
- C : Open card door
- F10 : Power down switch
- F1 : show this help
Setting BOOTDISK flag to FFFFFFFF
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: ITCM <- 0x6
FFFF00CC: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC000307D
FFFF00CC: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC004307D
FFFF00D8: MCR p15,0,Rd,cr9,cr1,0: DTCM <- 0x40000006
FFFF00E0: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC004307D
FFFF00E0: 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
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x75480
Now jump to AUTOEXEC.BIN!!
00874EAC: MCR p15, ... : CACHEMAINT x770 (omitted)
00874EAC: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
00C80694: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
00C8069C: MCR p15,0,Rd,cr9,cr0,1: ILockDown <- 0x80000000
00C806A4: MCR p15,0,Rd,cr9,cr0,1: ILockDown <- 0x1
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x0
00C806B0: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x20
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x20
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x40
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x40
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x60
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x60
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x80
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x80
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xA0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xA0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xC0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xC0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xE0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xE0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x100
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x100
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x120
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x120
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x140
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x140
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x160
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x160
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x180
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x180
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x200
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x200
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x220
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x220
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x240
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x240
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x260
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x260
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x280
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x280
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x300
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x300
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x320
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x340
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x340
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x360
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x380
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x380
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x400
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x400
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x420
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x420
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x440
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x440
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x460
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x460
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x480
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x480
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x500
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x500
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x520
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x520
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x540
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x540
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x560
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x560
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x580
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x580
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x600
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x600
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x620
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x620
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x640
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x640
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x660
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x660
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x680
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x680
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x700
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x700
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x720
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x720
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x740
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x740
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x760
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x760
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x780
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x780
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7E0
00C806F8: MCR p15, ... : CACHEMAINT x256 (omitted)
00C80718: MCR p15,0,Rd,cr9,cr0,0: DLockDown <- 0x80000000
00C80720: MCR p15,0,Rd,cr9,cr0,0: DLockDown <- 0x1
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x0
00C8072C: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x20
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x20
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x40
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x40
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x60
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x60
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x80
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x80
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xA0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xA0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xC0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xC0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xE0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xE0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x100
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x100
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x120
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x120
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x140
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x140
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x160
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x160
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x180
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x180
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x200
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x200
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x220
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x220
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x240
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x240
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x260
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x260
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x280
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x280
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x300
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x300
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x320
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x340
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x340
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x360
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x380
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x380
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x400
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x400
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x420
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x420
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x440
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x440
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x460
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x460
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x480
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x480
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x500
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x500
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x520
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x520
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x540
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x540
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x560
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x560
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x580
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x580
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x600
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x600
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x620
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x620
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x640
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x640
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x660
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x660
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x680
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x680
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x700
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x700
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x720
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x720
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x740
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x740
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x760
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x760
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x780
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x780
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7E0
00C80430: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
Lockdown read 2
00C80434: MRC p15,3,Rd,cr15,cr2,0: DcacheTag -> 0x0
00C803BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xFE1296C8
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x324
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE12FFF1E
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x328
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE92D400E
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x32C
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE59F0254
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x330
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE3A010FF
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x334
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE5CD1008
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x338
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE3A01000
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x33C
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE58D0000
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xC80480
Cache patch: [FE0C3B20] <- C80480 (was FE1296C8)
00C803F4: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
Lockdown read 1
00C803F8: MRC p15,3,Rd,cr15,cr1,0: IcacheTag -> 0x0
00C803A8: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE92D4010
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x364
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE24DD018
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x368
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE28F0F9A
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x36C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEBFFFDB5
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x370
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB015F55
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0160D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x378
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0082D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x37C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB01961C
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A018C8
Cache patch: [FE0C1B74] <- E3A018C8 (was E3A0160D)
When I run ./run_canon_fw.sh 1300D,firmware="boot=1"
I get multiple:
[MPU] Received: 06 04 09 00 00 00 (unknown - PROP_LV_LENS)
[MPU] Received: 08 06 04 20 00 00 00 00 (unknown - unnamed)
[MPU] Received: 06 05 04 1f 00 00 (unknown - unnamed)
[MPU] Received: 06 05 04 1c 0c 00 (unknown - unnamed)
[MPU] Received: 08 07 03 55 00 00 00 00 (unknown - PROP 8003005A)
[MPU] Received: 06 05 03 56 00 00 (unknown - PROP 8003005B)
[MPU] Received: 08 07 01 3b ff ff 00 00 (unknown - PROP_USBDEVICE_CONNECT)
[MPU] Received: 08 07 01 3b ff 00 00 00 (unknown - PROP_USBDEVICE_CONNECT)
[MPU] Received: 06 05 03 07 16 00 (unknown - PROP_BURST_COUNT)
[MPU] Received: 0a 08 03 06 00 00 00 16 00 00 (unknown - PROP_AVAIL_SHOT)
How can I solve these unknowns?
Hi all I'm super keen to help out with T6 work. Are these instructions still valid to setup my dev environment?
https://www.magiclantern.fm/forum/index.php?topic=991.0
Quote from: critix on January 16, 2019, 06:51:58 PM
How can I solve these unknowns?
If you look in the qemu-eos/qemu-2.5.0/hw/eos/mpu_spells directory you'll see that there is no file for the 1300D. You can create one. The way to do it is to use one of the branches that will create a startup log with mpu information in the log. Then from the mpu/spells directory run this:
python extract_init_spells.py [path to your startup log] > 1300D.hI believe I used the dm-spy-experiments branch compiled with the CONFIG_DEBUG_INTERCEPT_STARTUP option. There are other branches like the io_trace branch that can also create startup logs. I remember having to fiddle around with it for a while to get the mpu codes to show up in the log.
Quote from: rambutan2000 on January 17, 2019, 02:03:22 AM
Hi all I'm super keen to help out with T6 work. Are these instructions still valid to setup my dev environment?
https://www.magiclantern.fm/forum/index.php?topic=991.0
Yeah, you can start over there.
Read from here:
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst)
and from here:
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst (https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/HACKING.rst)
Hello
At @dfort's advice, I made a new dm-spy-experiments, called 1300D-dm-spy-experiments. I'm working on.
I made a manual merge with the 1300D branch. But there are emulation problems:
./run_canon_fw.sh 1300D,firmware=boot=1 &
DebugMsg=0xFE11F394 (from GDB script)
Lockdown read 1
Lockdown read 1
Lockdown read 0
Lockdown read 0
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
Lockdown read 5
Lockdown read 5
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: eos.ram_uncached
F0000000 - F1FFFFFF: eos.rom0
F2000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F9FFFFFF: eos.rom1
FA000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.mmio
[EOS] loading './1300D/ROM0.BIN' to 0xF0000000-0xF1FFFFFF
[EOS] mirrored data; unique 0x4 bytes repeated 0x800000 times
[EOS] loading './1300D/ROM1.BIN' to 0xF8000000-0xF9FFFFFF
[MPU] warning: non-empty spell #11 (PROP_CARD2_STATUS) has duplicate(s): #52
[MPU] warning: non-empty spell #20 (PROP_TFT_STATUS) has duplicate(s): #37 #38 #75
[MPU] warning: non-empty spell #35 (PROP_VIDEO_MODE) has duplicate(s): #36
[MPU] warning: non-empty spell #43 (PROP_TFT_STATUS) has duplicate(s): #41 #42 #44 #46
[MPU] Available keys:
- Arrow keys : Navigation
- [ and ] : Main dial (top scrollwheel)
- SPACE : SET
- DELETE : guess (press only)
- M : MENU (press only)
- P : PLAY (press only)
- I : INFO/DISP (press only)
- Q : guess (press only)
- L : LiveView (press only)
- A : Av
- Z/X : Zoom in/out
- Shift : Half-shutter
- 0/9 : Mode dial (press only)
- V : Movie mode (press only)
- B : Open battery door
- C : Open card door
- F10 : Power down switch
- F1 : show this help
Setting BOOTDISK flag to FFFFFFFF
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: ITCM <- 0x6
FFFF00CC: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC000307D
FFFF00CC: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC004307D
FFFF00D8: MCR p15,0,Rd,cr9,cr1,0: DTCM <- 0x40000006
FFFF00E0: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC004307D
FFFF00E0: 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
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x906C0
Now jump to AUTOEXEC.BIN!!
008900EC: MCR p15, ... : CACHEMAINT x770 (omitted)
008900EC: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
00C80694: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
00C8069C: MCR p15,0,Rd,cr9,cr0,1: ILockDown <- 0x80000000
00C806A4: MCR p15,0,Rd,cr9,cr0,1: ILockDown <- 0x1
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x0
00C806B0: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x20
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x20
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x40
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x40
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x60
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x60
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x80
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x80
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xA0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xA0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xC0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xC0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xE0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xE0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x100
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x100
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x120
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x120
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x140
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x140
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x160
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x160
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x180
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x180
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x200
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x200
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x220
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x220
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x240
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x240
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x260
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x260
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x280
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x280
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x300
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x300
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x320
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x340
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x340
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x360
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x380
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x380
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x400
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x400
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x420
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x420
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x440
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x440
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x460
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x460
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x480
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x480
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x500
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x500
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x520
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x520
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x540
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x540
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x560
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x560
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x580
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x580
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x600
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x600
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x620
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x620
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x640
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x640
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x660
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x660
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x680
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x680
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6E0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x700
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x700
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x720
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x720
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x740
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x740
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x760
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x760
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x780
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x780
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7A0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7A0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7C0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7C0
00C806BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7E0
00C806B8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7E0
00C806F8: MCR p15, ... : CACHEMAINT x256 (omitted)
00C80718: MCR p15,0,Rd,cr9,cr0,0: DLockDown <- 0x80000000
00C80720: MCR p15,0,Rd,cr9,cr0,0: DLockDown <- 0x1
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x0
00C8072C: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x20
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x20
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x40
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x40
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x60
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x60
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x80
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x80
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xA0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xA0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xC0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xC0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xE0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xE0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x100
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x100
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x120
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x120
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x140
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x140
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x160
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x160
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x180
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x180
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x200
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x200
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x220
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x220
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x240
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x240
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x260
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x260
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x280
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x280
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x300
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x300
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x320
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x340
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x340
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x360
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x380
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x380
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x400
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x400
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x420
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x420
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x440
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x440
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x460
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x460
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x480
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x480
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x500
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x500
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x520
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x520
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x540
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x540
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x560
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x560
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x580
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x580
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x600
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x600
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x620
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x620
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x640
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x640
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x660
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x660
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x680
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x680
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6E0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x700
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x700
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x720
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x720
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x740
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x740
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x760
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x760
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x780
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x780
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7A0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7A0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7C0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7C0
00C80738: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7E0
00C80734: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7E0
00C80430: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
Lockdown read 2
00C80434: MRC p15,3,Rd,cr15,cr2,0: DcacheTag -> 0x0
00C803BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xFE1296C8
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x324
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE12FFF1E
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x328
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE92D400E
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x32C
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE59F0254
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x330
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE3A010FF
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x334
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE5CD1008
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x338
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE3A01000
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x33C
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE58D0000
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xC80480
Cache patch: [FE0C3B20] <- C80480 (was FE1296C8)
00C803F4: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
Lockdown read 1
00C803F8: MRC p15,3,Rd,cr15,cr1,0: IcacheTag -> 0x0
00C803A8: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE92D4010
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x364
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE24DD018
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x368
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE28F0F9A
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x36C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEBFFFDB5
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x370
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB015F55
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0160D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x378
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0082D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x37C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB01961C
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A018C8
Cache patch: [FE0C1B74] <- E3A018C8 (was E3A0160D)
I know the 1300D is different from the other devices, so I think I'm missing something. Here is the link to the branch made with all the changes made so far:
https://bitbucket.org/ccritix/magic-lantern/branch/1300D-dm-spy-experiments (https://bitbucket.org/ccritix/magic-lantern/branch/1300D-dm-spy-experiments)
Sometimes it stops at the line:
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A018C8
Cache patch: [FE0C1B74] <- E3A018C8 (was E3A0160D)
@a1ex, can you help me?
Thank you.
Now... i got: [BOOT] out of memory.
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x907C0
Now jump to AUTOEXEC.BIN!!
0089018C: MCR p15, ... : CACHEMAINT x770 (omitted)
0089018C: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
[boot] copy_and_restart 0xc80000 (13107200)
[BOOT] changing init_task from 0xfe1296c8 (-32336184) to 0xc804b0 (13108400)
[BOOT] autoexec.bin loaded at C80000 - D00340.
[BOOT] calling local pre_init_task C803E4...
[BOOT] changing AllocMem end address: D00000 -> C80000.
0xfe0c1b74: e3a0160d mov r1, #13631488 ; 0xd00000
0xfe0c1b78: e3a0082d mov r0, #2949120 ; 0x2d0000
0xfe0c1b74: e3a018c8 mov r1, #13107200 ; 0xc80000
0xfe0c1b78: e3a0082d mov r0, #2949120 ; 0x2d0000
[BOOT] calling pre_init_task C80C9C...
[BOOT] installing task dispatch hook at 0x35924 (219428)
[BOOT] reserved 524288 bytes for ML (used 525120)
[BOOT] out of memory.
This is what I get when compiling with:
CONFIG_MMIO_TRACE=y
I'm getting better, right? :D
Is it booting into the Canon menu? Are you able to save a startup log? Compile with:
CONFIG_DEBUG_INTERCEPT_STARTUP=y
Yes, it boots in the Canon menu but does not save any logs. On the contrary, I have a Crash:
ASSERT: 0
at SystemIF::KerSem.c:354, PropMgr:337c
lv:0 mode:0
PropMgr stack: 151240 [151360-150360]
0xUNKNOWN @ 41fc:151350
0xUNKNOWN @ fe2c2170:151328
0xFE2BE970 @ fe10bc8c:151310
0xUNKNOWN @ fe2be9a0:151300
0xUNKNOWN @ fe2bea28:1512e0
0xUNKNOWN @ fe294cf4:1512a8
0xUNKNOWN @ c9c5b8:151280
0x00003CBC @ 3378:151278
0x00C80378 @ c807cc:151240
Magic Lantern version : Nightly.2019Jan21.1300D110
Mercurial changeset : b8ed21b80b54+ (dm-spy-experiments)
Built on 2019-01-21 07:59:00 UTC by root@cristi.
Free Memory : 260K + 898K
I compiled with:
CONFIG_DEBUG_INTERCEPT_STARTUP=y
I tried with io_trace branch but unfortunately qemu stops ... as in dm-spy-experiments:
00C80430: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
Lockdown read 2
00C80434: MRC p15,3,Rd,cr15,cr2,0: DcacheTag -> 0x0
00C803BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xFE1296C8
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x324
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE12FFF1E
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x328
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE92D400E
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x32C
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE59F0254
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x330
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE3A010FF
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x334
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE5CD1008
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x338
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE3A01000
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x33C
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE58D0000
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xC80480
Cache patch: [FE0C3B20] <- C80480 (was FE1296C8)
00C803F4: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
Lockdown read 1
00C803F8: MRC p15,3,Rd,cr15,cr1,0: IcacheTag -> 0x0
00C803A8: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE92D4010
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x364
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE24DD018
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x368
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE28F0F9A
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x36C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEBFFFDB5
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x370
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB015F55
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0160D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x378
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0082D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x37C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB01961C
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A018C8
Cache patch: [FE0C1B74] <- E3A018C8 (was E3A0160D)
I do not know what else I can do ... what I do wrong?
Thanks.
Looks like I'm wrong ... it looks like qemu is not blocking ....
I run:
./run_canon_fw.sh 1300D,firmware="boot=1" -d tasks
and here is the result ...
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A018C8
Cache patch: [FE0C1B74] <- E3A018C8 (was E3A0160D)
Task switch to idle:fe0c08d0 at [idle:197c:197c]
Task switch to init:5cc at [init:1d84:1d84]
Task switch to idle:fe0c08d0 at [idle:197c:197c]
Task switch to init:5cc at [init:1d84:1d84]
Task switch to idle:fe0c08d0 at [idle:197c:197c]
Task switch to init:5cc at [init:1d84:1d84]
Task switch to idle:fe0c08d0 at [idle:197c:197c]
Task switch to init:5cc at [init:1d84:1d84]
Task switch to idle:fe0c08d0 at [idle:197c:197c]
Task switch to init:5cc at [init:1d84:1d84]
Task switch to idle:fe0c08d0 at [idle:197c:197c]
Task switch to init:5cc at [init:1d84:1d84]
Task switch to idle:fe0c08d0 at [idle:197c:197c]
Task switch to init:5cc at [init:1d84:1d84]
....
Have you been able to save a startup log yet? I needed a lot of help before I was able to get the first one saved on the EOSM2 (https://www.magiclantern.fm/forum/index.php?topic=15895.msg188224#msg188224). Even then it took a few months more work before a1ex felt it was safe to turn on the camera bootflag (https://www.magiclantern.fm/forum/index.php?topic=15895.msg195251#msg195251). Of course you have more coding knowledge that I do so it probably won't take you as long.
I have succeeded with io_trace_full to start in qemu, but the same ... crash:
ASSERT: 0
at SystemIF::KerSem.c:354, PropMgr:337c
lv:0 mode:0
PropMgr stack: 151240 [151360-150360]
0xUNKNOWN @ 41fc:151350
0xUNKNOWN @ fe2c2170:151328
0xFE2BE970 @ fe10bc8c:151310
0xUNKNOWN @ fe2be9a0:151300
0xUNKNOWN @ fe2bea28:1512e0
0xUNKNOWN @ fe294cf4:1512a8
0xUNKNOWN @ c9cbb8:151280
0x00003CBC @ 3378:151278
0x00C80378 @ c80804:151240
Magic Lantern version : Nightly.2019Jan25.1300D110
Mercurial changeset : 296fdfb5f8d0+ (io_trace_full)
Built on 2019-01-25 16:23:14 UTC by root@cristi.
Free Memory : 260K + 898K
I do not manage to write my logs at all ...
A big step forward ...
I was able to create the DM-0000.LOG file, but with 0 bytes.
I found what was wrong ... now I'm trying to find the solution to save the log ...
I'm not leaving, I want to run ML on 1300D :D
Unpatch error at fe2993b4 (NOT_PATCHED)
Unpatch error at fe10fa70 (NOT_PATCHED)
Unpatch error at fe11f394 (NOT_PATCHED)
[NotifyBox] dm-0000.log: saved 0 bytes.
Keep it up! ;-)
Offtopic: If you have some 3 minutes with your 500D: Run this test (https://www.magiclantern.fm/forum/index.php?topic=9848.msg210958#msg210958) and report back. Interested if it is 7D specific or affects DIGIC IV cams altogether.
Okay, I'll test, but with what build?
Quote from: critix on January 26, 2019, 06:41:45 PM
Okay, I'll test, but with what build?
To keep it safe: Recent nightly, please!
Hello ! :)
I can't help you, I'm sorry but I just want to say thank you for what you're doing, and good luck ! I really want to see ML on the 1300D so... I send you lot of love and luck ! :D
Okay ... a small step forward in working with logs ... but ... other problems ...
A1ex, can you help me?
[boot] copy_and_restart 0xc80000 (13107200)
[BOOT] changing init_task from 0xfe1296c8 (-32336184) to 0xc804b0 (13108400)
[BOOT] autoexec.bin loaded at C80000 - CFCE40.
[BOOT] calling local pre_init_task C803E4...
[BOOT] changing AllocMem end address: D00000 -> C80000.
0xfe0c1b74: e3a0160d mov r1, #13631488 ; 0xd00000
0xfe0c1b78: e3a0082d mov r0, #2949120 ; 0x2d0000
0xfe0c1b74: e3a018c8 mov r1, #13107200 ; 0xc80000
0xfe0c1b78: e3a0082d mov r0, #2949120 ; 0x2d0000
[BOOT] calling pre_init_task C80CA8...
[BOOT] installing task dispatch hook at 0x35924 (219428)
[BOOT] reserved 524288 bytes for ML (used 511552)
ICache: 8192b, idx=7e0 tag=fffff800 word=1c seg=c0000000
Jump range error: cf37a0 -> fe2993b8
Patch error at fe2993b4 (jump out of range)
Jump range error: cf37a0 -> fe10fa74
Patch error at fe10fa70 (jump out of range)
[BOOT] starting init_task 14B70C...
K404 READY
< Error Exception >
TYPE : undefined
ISR : FALSE
TASK ID : 00020002
TASK Name : init
R 0 : 00000000
R 1 : 00000001
R 2 : fe123d6c
R 3 : 00000001
R 4 : 00031e44
R 5 : 00000000
R 6 : 00c804b0
R 7 : 19980218
R 8 : 19980218
R 9 : 19980218
R10 : 19980218
R11 : 19980218
R12 : 0014bb40
R13 : 0014b6d8
R14 : fe123c98
PC : fccc1a34
CPSR : 80000093
[****] Starting task fe2bafd0(0) PowerMgr
I'll try, but the solution is not straightforward.
Previously covered in replies #120 and #239.
Edit: confirmed the dm-spy-experiments branch is not working, even with minimal logging options (dm_spy_extra* commented out).
Need to use a long jump for patching DebugMsg. It started to work - to some extent - with this:
int err = patch_instruction(DebugMsg_addr, MEM(DebugMsg_addr), FAR_CALL_INSTR, "dm-spy: log all DebugMsg calls");
err |= patch_instruction(DebugMsg_addr + 4, MEM(DebugMsg_addr + 4), &my_DebugMsg, "dm-spy: log all DebugMsg calls");
The semaphore error appears to come from beep() - somebody's calling that before beep_init. Disabled beeps, it went further.
When trying to save the log, it fails with:
[dm-spy] captured 128kB of messages
[NotifyBox] Pretty-printing... (128kB)
[ CtrlSrv:fe49c7fc ] (83:02) DlgShootOlc.c LOCAL_DIALOG_REFRESH
qemu: fatal: Trying to execute code outside RAM or ROM at 0x87274218
That was because I've patched two instructions from DebugMsg, to implement the long call, but when uninstalling the logging hook, I should have "unpatched" both instructions. Rookie mistake.
Now, the hard part - clean up the code and commit it :D
Still need to find a general solution for patching arbitrary functions in Canon code (i.e. to implement long jump support in the patch manager).
Hi! When will compile "hello world" or memory benchmark to run on hardware? :)
I have EOS 1300D and i'm very wait ML on this camera.
Hello i have a 1300d and i have watched this thread for 2 years
Theres unfortunatelly still no magic lantern available for my cam.
So i wanted to ask when it will be available.
And i am new here but do you think that i can help you. If yes how
Can i do it?
Thanks for your reply beforly
Quote from: Rebel99 on March 07, 2019, 07:56:10 PM
So i wanted to ask when it will be available.
ML project has no schedule, no master plan, no release dates, no milestones. Therefore your question doesn't make sense.
Quote from: Rebel99 on March 07, 2019, 07:56:10 PM
And i am new here but do you think that i can help you. If yes how
Can i do it?
Begin with sticky tweet: https://twitter.com/autoexec_bin
Quote from: a1ex on January 28, 2019, 12:56:47 PM
I'll try, but the solution is not straightforward.
....
Now, the hard part - clean up the code and commit it :D
Still need to find a general solution for patching arbitrary functions in Canon code (i.e. to implement long jump support in the patch manager).
Alex, you have not succeeded to find solution for patching arbitrary functions?
It seems that without being able to solve this part, it can not go further with ML to 1300D, 2000D ...
Thanks
Just found out about this project. I'll see what I can do about the patcher. Any info on the CPU ?
There is lots of information. Start here https://mobile.twitter.com/autoexec_bin
and here https://www.magiclantern.fm/forum/index.php?topic=11108.0
and here https://www.magiclantern.fm/forum/index.php?topic=991.0
Quote from: Rebel99 on March 07, 2019, 07:56:10 PM
Hello i have a 1300d and i have watched this thread for 2 years
Theres unfortunatelly still no magic lantern available for my cam.
So i wanted to ask when it will be available.
And i am new here but do you think that i can help you. If yes how
Can i do it?
Thanks for your reply beforly
Well, given that the project takes place based on the efforts of volunteers, the straight answer is that ML/1300D will be available whenever it is ready, and not before.
There is certainly no schedule to be expected on the matter.
The recent discussions are showing that there are some peculiarities about the 1300D platform leading to confusing results. It sure would be nice if some "silver bullet" falls out that solves problems for this as well as other cameras, but it isn't going to happen until it all gets figured out.
I have qemu installed in Windows 10 WSL, Ubuntu - trying to run ./run_canon_fw.sh 1300D
without sudo it just says can't find ROM0.BIN
with sudo it says this:
Quote
DebugMsg=0xFE11F394 (from GDB script)
Lockdown read 1
Lockdown read 1
Lockdown read 0
Lockdown read 0
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
Lockdown read 5
Lockdown read 5
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: eos.ram_uncached
F0000000 - F1FFFFFF: eos.rom0
F2000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F9FFFFFF: eos.rom1
FA000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.mmio
[EOS] loading './1300D/ROM0.BIN' to 0xF0000000-0xF1FFFFFF
[EOS] mirrored data; unique 0x4 bytes repeated 0x800000 times
qemu-system-arm: /home/test/qemu-eos/qemu-2.5.0/hw/arm/../eos/eos.c:407: check_rom_mirroring: Assertion `0' failed.
./run_canon_fw.sh: line 153: 988 Aborted (core dumped) env QEMU_EOS_DEBUGMSG="$QEMU_EOS_DEBUGMSG" $QEMU_PATH/arm-softmmu/qemu-system-arm -drive if=sd,format=raw,file=sd.img -drive if=ide,format=raw,file=cf.img -chardev socket,server,nowait,path=qemu.monitor$QEMU_JOB_ID,id=monsock -mon chardev=monsock,mode=readline -name $CAM -M $*
I'm not sure how to fix this. Any ideas?
Very good catch; there's no ROM0 on 1300D. Why did I think otherwise?! [my old dump has some valid strings, apparently copied or shadowed from ROM1, that's why.]
Comment out rom0_size in model_list.c. Will fix ASAP.
Regarding sudo - check permissions of your ROM files. Maybe something happens when copying them from the card (or when they cross the Windows/Linux barrier). I've only tested WSL on virtual machines, without giving them access to a real SD card.
Quote from: a1ex on April 24, 2019, 08:38:35 AM
Very good catch; there's no ROM0 on 1300D. Why did I think otherwise?! [my old dump has some valid strings, apparently copied or shadowed from ROM1, that's why.]
Comment out rom0_size in model_list.c. Will fix ASAP.
Regarding sudo - check permissions of your ROM files. Maybe something happens when copying them from the card (or when they cross the Windows/Linux barrier). I've only tested WSL on virtual machines, without giving them access to a real SD card.
Okay, now I get this - does this seem correct for where I'm at?
Quote
./run_canon_fw.sh 1300D &
DebugMsg=0xFE11F394 (from GDB script)
Lockdown read 1
Lockdown read 1
Lockdown read 0
Lockdown read 0
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
Lockdown read 5
Lockdown read 5
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: eos.ram_uncached
F8000000 - F9FFFFFF: eos.rom1
FA000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.mmio
[EOS] loading './1300D/ROM1.BIN' to 0xF8000000-0xF9FFFFFF
[MPU] warning: non-empty spell #11 (PROP_CARD2_STATUS) has duplicate(s): #52
[MPU] warning: non-empty spell #20 (PROP_TFT_STATUS) has duplicate(s): #37 #38 #75
[MPU] warning: non-empty spell #35 (PROP_VIDEO_MODE) has duplicate(s): #36
[MPU] warning: non-empty spell #43 (PROP_TFT_STATUS) has duplicate(s): #41 #42 #44 #46
[MPU] Available keys:
- Arrow keys : Navigation
- [ and ] : Main dial (top scrollwheel)
- SPACE : SET
- DELETE : guess (press only)
- M : MENU (press only)
- P : PLAY (press only)
- I : INFO/DISP (press only)
- Q : guess (press only)
- L : LiveView (press only)
- A : Av
- Z/X : Zoom in/out
- Shift : Half-shutter
- 0/9 : Mode dial (press only)
- V : Movie mode (press only)
- B : Open battery door
- C : Open card door
- F10 : Power down switch
- F1 : show this help
gtk initialization failed
[MPU] WARNING: forced shutdown.
For clean shutdown, please use 'Machine -> Power Down'
(or 'system_powerdown' in QEMU monitor.)
You need Xming installed in windows and turned on.
https://sourceforge.net/projects/xming/ (https://sourceforge.net/projects/xming/)
or
http://www.straightrunning.com/XmingNotes/ (http://www.straightrunning.com/XmingNotes/)
Then run again.
Quote from: critix on April 24, 2019, 04:54:26 PM
You need Xming installed in windows and turned on.
https://sourceforge.net/projects/xming/ (https://sourceforge.net/projects/xming/)
or
http://www.straightrunning.com/XmingNotes/ (http://www.straightrunning.com/XmingNotes/)
Then run again.
Nice thanks - I'm gonna reread the thread and try and catch up to where it currently is - or is this where it currently is?
What's the next move on this? I'm willing to do whatever on my T6 - I bought it specifically as a camera that I don't have to worry about (I already had the T6i). I got the GUI up and working in QEMU, wondering what to do next though.
Quote from: alawiggle on April 30, 2019, 02:19:40 AM
What's the next move on this?
This camera is stuck on trying to generate a startup log. Something to do with making "long jumps" in ARM code. Read replies #120 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg195776#msg195776), #230 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg204261#msg204261) and #297 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg211084#msg211084) to get a deeper understanding of the problem.
Seems like every camera has its own particular quirks. Read through the ML on EOS-M2 (https://www.magiclantern.fm/forum/index.php?topic=15895.0) topic for some good tips. Note that we ran into several issues on that camera. At one point I was ready to give up but eventually we (well mostly a1ex) got it working on the camera.
Also note that we had some "long jump" issues recently on the 7D so you might want to check out how that one was solved on the 12-bit (and 10-bit) RAW video development discussion (https://www.magiclantern.fm/forum/index.php?topic=5601.msg212686#msg212686).
Quote from: dfort on April 30, 2019, 04:22:42 AM
This camera is stuck on trying to generate a startup log. Something to do with making "long jumps" in ARM code. Read replies #120 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg195776#msg195776), #230 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg204261#msg204261) and #297 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg211084#msg211084) to get a deeper understanding of the problem.
Seems like every camera has its own particular quirks. Read through the ML on EOS-M2 (https://www.magiclantern.fm/forum/index.php?topic=15895.0) topic for some good tips. Note that we ran into several issues on that camera. At one point I was ready to give up but eventually we (well mostly a1ex) got it working on the camera.
Also note that we had some "long jump" issues recently on the 7D so you might want to check out how that one was solved on the 12-bit (and 10-bit) RAW video development discussion (https://www.magiclantern.fm/forum/index.php?topic=5601.msg212686#msg212686).
Mine can move through the menus, is that about right? I guess I'm trying to see how i get to that post someone had of hello world showing on the screen? or is that even relevant at the moment
Yes, all that works--emulation in QEMU, Hello World. The problem is when trying to create a startup log using ML. Without being able to do that is it not possible to get some of the addresses needed to continue the port. Read through the EOSM2 discussion (https://www.magiclantern.fm/forum/index.php?topic=15895.0) to see why that is so important. I'm currently away from home on a vacation and don't have time to re-read all of it and point out specific posts.
Quote from: dfort on April 30, 2019, 02:09:27 PM
Yes, all that works--emulation in QEMU, Hello World. The problem is when trying to create a startup log using ML. Without being able to do that is it not possible to get some of the addresses needed to continue the port. Read through the EOSM2 discussion (https://www.magiclantern.fm/forum/index.php?topic=15895.0) to see why that is so important. I'm currently away from home on a vacation and don't have time to re-read all of it and point out specific posts.
How do I get hello world working? I've read this entire thread, but feel like I'm missing a step - it seems to hinge on using another branch to form off of? Or it hints at having magic lantern already installed?
Sorry, I really have read the guides - they seem to, understandably, focus on cameras where ML already works and I don't have another camera to see how it's "supposed" to work
For run "Hello Word" try this (of course, from qemu):
Quote from: a1ex on August 20, 2018, 09:53:25 PM
Hopefully done (https://bitbucket.org/hudson/magic-lantern/commits/a39719e958bc327e72132a0936f3caff412d3731); I could finally compile the installer and other minimal examples!
cd minimal/hello-world
make MODEL=1300D clean
make MODEL=1300D install_qemu CONFIG_QEMU=y
Quote from: critix on April 30, 2019, 05:13:46 PM
For run "Hello Word" try this (of course, from qemu):
I tried that, but I get this:
Quote
test@Nicolas:~/magic-lantern/minimal/hello-world$ make MODEL=1300D clean
../../platform/Makefile.platform.base:19: FW_VERSION for 1300D is not defined
../../platform/Makefile.platform.base:60: *** ROMBASEADDR is not defined. Stop.
test@Nicolas:~/magic-lantern/minimal/hello-world$
I'm thinking I need to make a directory called 1300D.110 in platform, but unsure what should go into it.
Yes, create directory 1300D in minimal, and in this directory create file "Makefile" with this:
MODEL=1300D
include ../Makefile.minimal
Then run again.
Quote from: critix on April 30, 2019, 06:11:12 PM
Yes, create directory 1300D in minimal, and in this directory create file "Makefile" with this:
MODEL=1300D
include ../Makefile.minimal
Then run again.
Same error - it doesn't have anything to do with Makefile.platform.base ?
Is there code I could just pull that has all this up to that point?
@alawiggle - looks to me like you are not on the right branch. Make sure you are using the 1300D branch:
cd ~/magic-lantern
hg update 1300D
cd minimal/hello-world
make MODEL=1300D
Next copy the autoexec.bin from the onto the QEMU sd card. I'm on a Mac so I just double click qemu-eos/sd.img, drag in autoexec.bin into the root directory, eject the virtual card and run it.
cd ~/qemu-eos
./run_canon_fw.sh 1300D,firmware="boot=1" -d debugmsg
@critix - I've been meaning to getting around to merging your pull requests for the 1300D and 4000D but want to come up with a strategy. What do you think, make a new 4000D branch or a new digic4+ branch? Just adding the 4000D code into the 1300D branch would probably be confusing.
I think it would be better to create a new digic4+ branch because the 1300D is not the only digic4+.
Sounds good. I'm still on vacation so let's take care of this next week.
Quote from: dfort on May 01, 2019, 02:23:17 PM
@alawiggle - looks to me like you are not on the right branch. Make sure you are using the 1300D branch:
cd ~/magic-lantern
hg update 1300D
cd minimal/hello-world
make MODEL=1300D
Next copy the autoexec.bin from the onto the QEMU sd card. I'm on a Mac so I just double click qemu-eos/sd.img, drag in autoexec.bin into the root directory, eject the virtual card and run it.
Maybe this is where I'm lost - thus far I've just been using the ROM dumps that the FIR file gives me. I'm gonna try uninstalling the whole thing and starting new. I'll try and put the steps I've taken that way if anything seems wrong i can pinpoint which it is.
Quote from: dfort on May 01, 2019, 02:23:17 PM
@alawiggle - looks to me like you are not on the right branch. Make sure you are using the 1300D branch:
cd ~/magic-lantern
hg update 1300D
cd minimal/hello-world
make MODEL=1300D
Next copy the autoexec.bin from the onto the QEMU sd card. I'm on a Mac so I just double click qemu-eos/sd.img, drag in autoexec.bin into the root directory, eject the virtual card and run it.
Reinstalled everything - when I run "hg update 1300D" it just says "abort: uncommitted changes
(commit or update --clean to discard changes)"
Which I guess means I'm up to date, but I get the same errors as before "../../platform/Makefile.platform.base:19: FW_VERSION for 1300D is not defined
../../platform/Makefile.platform.base:60: *** ROMBASEADDR is not defined. Stop."
So must have something to do with that sd card thing?
Okay, I see - I hadn't switched to the 1300D branch (it wasn't letting me due to an unsaved commit or something).
Still unsure of the mounting of this sd.img card, it just gives me this:
Quote
test@Nicolas:~/qemu-eos$ sudo ./mount.sh
This will mount sd.img and cf.img as a loopback device.
Please enter your password (of course, after reviewing what this script does).
Kernel not configured for semaphores (System V IPC). Not using udev synchronisation code.
/dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.145 (2017-11-03) and kernel driver (unknown version).
device mapper prerequisites not met
Kernel not configured for semaphores (System V IPC). Not using udev synchronisation code.
/dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.145 (2017-11-03) and kernel driver (unknown version).
device mapper prerequisites not met
Done.
To remove the device mappings, run:
sudo kpartx -dv sd.img
sudo kpartx -dv cf.img
Quote from: alawiggle on May 02, 2019, 12:49:32 AM
Okay, I see - I hadn't switched to the 1300D branch (it wasn't letting me due to an unsaved commit or something).
Use the -C/--clean option, uncommitted changes are discarded.
hg update -C 1300DQuote from: alawiggle on May 02, 2019, 12:49:32 AM
Still unsure of the mounting of this sd.img card, it just gives me this:
Have you tried just double clicking on the sd.img file icon? It looks like you have a Linux distribution that is using a different method to mount disk image files. The ROM dumps belong in the ~/qemu-eos/1300D directory. Also note that the dump needs to be patched. Check back on Reply #198 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg201830#msg201830) for instructions on how to do this.
Quote from: dfort on May 02, 2019, 04:43:21 AM
Have you tried just double clicking on the sd.img file icon? It looks like you have a Linux distribution that is using a different method to mount disk image files. The ROM dumps belong in the ~/qemu-eos/1300D directory. Also note that the dump needs to be patched. Check back on Reply #198 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg201830#msg201830) for instructions on how to do this.
I'm using Windows 10 WSL - which is the problem I think. Can't mount it in windows, it claims it's corrupted. mouning in bash/ubuntu just says unknown filesystem type.
Thanks, I did the -C thing and had already patched the ROM files - Ill figure it out in the morning, should have just used a VM probably would have been easier
For copy to img, use:
./mtools_copy_ml.sh ../magic-lantern/minimal/hello-world/zip/
Quote from: critix on May 02, 2019, 09:11:00 AM
For copy to img, use:
./mtools_copy_ml.sh ../magic-lantern/minimal/hello-world/zip/
I didn't have a ML directory yet (I don't think) so did this:
Quote
https://bitbucket.org/hudson/magic-lantern/src/qemu/contrib/qemu/README.rst#rst-header-running-magic-lantern
# from the magic-lantern directory
cd platform/1300D.110
make clean; make
make install
But it throws these errors after make install:
Quote
WARNING: module edmac failed to build, deleting
********************************************************
make[5]: Entering directory '/home/test/magic-lantern/modules/edmac'
[ RM ] edmac.o edmac_util.o edmac_test.o md5.o edmac.mo edmac.sym edmac.dep edmac.zip module_strings.h hgdiff.tmp *.o *.d *.dep *.sym hgstamp
make[5]: Leaving directory '/home/test/magic-lantern/modules/edmac'
make[4]: Leaving directory '/home/test/magic-lantern/modules/edmac'
make[3]: Leaving directory '/home/test/magic-lantern/modules'
[ MKDIR ] ML directory structure...
cp ../modules/*/*.mo /ML/modules/
cp: cannot stat '../modules/*/*.mo': No such file or directory
Makefile:31: recipe for target 'install' failed
make[2]: *** [install] Error 1
make[2]: Leaving directory '/home/test/magic-lantern/modules'
../../Makefile.inc:27: recipe for target 'CONFIG_MODULES_install' failed
make[1]: *** [CONFIG_MODULES_install] Error 2
make[1]: Leaving directory '/home/test/magic-lantern/platform/1300D.110'
../../Makefile.inc:34: recipe for target 'install' failed
make: *** [install] Error 2
I think this is the error if no module was built on install and install_qemu targets.
There's a simple fix for that:
https://bitbucket.org/calle2010/obsolete-magic-lantern/commits/7c425ae2c0d0e17855e4811dcb6ac0ae998dc00f
I think I should create a PR.
Also you can save a lot of time if you add
ML_MODULES=
to your make comand line. It will skip module builds which anyways fail at this stage.
mtools_copy_ml.sh is in qemu directory.
Please read here:
https://www.magiclantern.fm/forum/index.php?topic=2864.msg190596#msg190596 (https://www.magiclantern.fm/forum/index.php?topic=2864.msg190596#msg190596)
For "Hello Word":
hg update 1300D
cd minimal/hello-world
make MODEL=1300D
make install not work yet on 1300D.
Quote from: calle2010 on May 02, 2019, 07:22:22 PM
I think this is the error if no module was built on install and install_qemu targets.
There's a simple fix for that:
https://bitbucket.org/calle2010/obsolete-magic-lantern/commits/7c425ae2c0d0e17855e4811dcb6ac0ae998dc00f
I think I should create a PR.
Also you can save a lot of time if you add
ML_MODULES=
to your make comand line. It will skip module builds which anyways fail at this stage.
Thanks, this helped.
I think I got it, now it's showing this:
(https://i.imgur.com/zflBfuG.jpg)
Is this normal? Never seen this screen before so it's progress on my end to me. Sorry for the back and forth, I see this info is available it just seems spread out a lot, especially if it's for a camera that isn't working yet - this is to be expected of course though
If I'm not mistaken, it seems like this error is when you have another version of ROM than the one you work with.
Quote from: critix on May 06, 2019, 11:26:58 AM
If I'm not mistaken, it seems like this error is when you have another version of ROM than the one you work with.
Not sure how that can be - ive only used the only one I have?
I was told to comment out the ROM0 size line in model_list.c to fix to - perhaps that's it?
One thing though, I can't get the md5 to match on the ROM0 (I think) - no matter what I do, what SD card size I use, it's always the same md5 and never matches.
Quote from: alawiggle on May 02, 2019, 07:56:32 PM
Is this normal?
The model detection error comes up if the computed ROM signature doesn't match the one in fw-signature.h. What did you define there?
At least in the digic6-dumper branch in reboot.c if you compile with CONFIG_QEMU=y it will print in Qemu the expected signature. Just put this to fw-signature.h.
Quote from: calle2010 on May 06, 2019, 07:57:55 PM
The model detection error comes up if the computed ROM signature doesn't match the one in fw-signature.h. What did you define there?
At least in the digic6-dumper branch in reboot.c if you compile with CONFIG_QEMU=y it will print in Qemu the expected signature. Just put this to fw-signature.h.
alex helped me in IRC, apparently I had firmware 1.1.0 / 4.4.7 37(0b) instead of 1.1.0 / 4.4.6 37(0b).
could anyone confirm if this is the right address for this:
NSTUB(0xFE14BCE4, LightMeasure_n_Callback_r0) /* present on 7D.203, 5D2.212 */
Not sure if it's even important for that on the 1300d, but wanna make sure I'm doing this right.
I'm just doing simple pattern checking but that doesn't look right. What camera are you checking this against? Only the 7D and 5D2 seem to have it.
Quote from: dfort on May 21, 2019, 07:25:43 AM
I'm just doing simple pattern checking but that doesn't look right. What camera are you checking this against? Only the 7D and 5D2 seem to have it.
None - I don't have any other cameras. Alex was saying that it's not used in the 1300D - he also said they leave stuff in they don't use. I had "found" this stub before I knew that though, so wanted to see if I had the right idea.
I was wondering, is there anyone who knows exactly what needs to happen with this, what I can do (or anyone else) can do to make some progress? I know there's the "next steps" post, but it seems like those are already done - if they aren't, Im not sure what isn't done.
Just want to try and move this along and help any way I can.
There are a couple of pull requests to update the 1300D stubs but it looks like they need some cleanup before merging into the main repository.
https://bitbucket.org/hudson/magic-lantern/pull-requests/933/1300d-found-stubs-by-matching-pattern-with/diff
https://bitbucket.org/hudson/magic-lantern/pull-requests/951/1300d-found-multiple-values-and-add-4000d/diff
Values found in PR
https://bitbucket.org/hudson/magic-lantern/pull-requests/933/1300d-found-stubs-by-matching-pattern-with/diff
are in PR:
https://bitbucket.org/hudson/magic-lantern/pull-requests/951/1300d-found-multiple-values-and-add-4000d/diff
Though I dont have expertise in reverse Engineering ROMs but yet I tried to dump the ROM which was a pretty easy task....
(https://drive.google.com/file/d/1F9KxtIFUUooxvCKUTcWs6lDWLsybYdJ0/view?usp=sharing)
Now what do I do?
Hi, is there a ML ROM available for 1300D? I went through the thread but I am bit confused, seems like work in progress, right?
Quote from: juvo on June 24, 2019, 10:15:22 PM
Hi, is there a ML ROM available for 1300D? I went through the thread but I am bit confused, seems like work in progress, right?
Same question from me.
Start reading this topic from the beginning. If you want to get involved download the firmware dumper for this camera and dump the ROM, set up a development environment -- including QEMU, patch the ROM, clone the ML repository and get started. Make sure you also check out the pull requests posted by critix, he has worked on this camera up a point where it is almost ready to run on real hardware.
Quote from: a1ex on January 28, 2019, 12:56:47 PM
Now, the hard part - clean up the code and commit it :D
Still need to find a general solution for patching arbitrary functions in Canon code (i.e. to implement long jump support in the patch manager).
If anyone has a deep enough understanding of ARM code to help figure this out then maybe we'll get ML working on this camera.
Has their been any movement on this ML build since July's post?
any progress on this? been watching this post all of 2019 to see if a finished version came out.
@ROME @vwnut8392
Pending someone with the requisite skill-set becoming involved, its unlikely this will progress any further.
I try to run in qemu ML on 1300D, but when I run
./run_canon_fw.sh 1300D, firmware="boot=1" I get the error
QuoteModel detection error.
If I run
./run_canon_fw.sh 1300D, firmware="boot=0" is ok.
I get the error after I commented on rom0_size in
model_list.cQuote from: a1ex on April 24, 2019, 08:38:35 AM
Comment out rom0_size in model_list.c. Will fix ASAP.
, because I received the error:
Quote[EOS] mirrored data; unique 0x4 bytes repeated 0x800000 times
qemu-system-arm: /home/cristi/qemu-eos/qemu-2.5.0/hw/arm/../eos/eos.c:407: check_rom_mirroring: Assertion `0' failed.
./run_canon_fw.sh: line 153: 988 Aborted (core dumped) env QEMU_EOS_DEBUGMSG="$QEMU_EOS_DEBUGMSG" $QEMU_PATH/arm-softmmu/qemu-system-arm -drive if=sd,format=raw,file=sd.img -drive if=ide,format=raw,file=cf.img -chardev socket,server,nowait,path=qemu.monitor$QEMU_JOB_ID,id=monsock -mon chardev=monsock,mode=readline -name $CAM -M $*
I run the sure_copy_from_contrib.sh script and it is ok now.
Quote from: critix on January 31, 2020, 08:27:15 AM
I ran the sure_copy_from_contrib.sh script and it is ok now.
It's (https://bitbucket.org/hudson/magic-lantern/branch/1300D) ready to use on 1300D?
ML is not running on 1300D yet.
What else are we missing to keep the progress moving in the right direction?
Unicorn level: A person skilled with C, assembler and reverse engineering embedded devices (ARM architecture) with lots of free time at hand.
Hi!
A new firmware version has appeared:
https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-1300d.html?type=firmware (https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-1300d.html?type=firmware)
Quote from: critix on March 18, 2020, 04:14:40 PM
Hi!
A new firmware version has appeared:
https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-1300d.html?type=firmware (https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-1300d.html?type=firmware)
Does this mean we could be closer to ML on our 1300D? :'(
Quote from: critix on March 18, 2020, 04:14:40 PM
Hi!
A new firmware version has appeared:
https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-1300d.html?type=firmware (https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-1300d.html?type=firmware)
is this good or bad?
is good:
Quote1. Corrects a PTP communications vulnerability.
2. Corrects a vulnerability related to firmware update.
Quote from: critix on March 30, 2020, 07:18:26 PM
is good:
Are we still waiting on Alex? My understanding wa that we needed him to publish a .FIR file to set camera bootflag? That's the last I heard and why I haven't bothered with this thread in a year lol
We still do not need the FIR file for bootflag.
We must first solve the problems for this device.
Read:
https://www.magiclantern.fm/forum/index.php?topic=17969.msg211084#msg211084 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg211084#msg211084)
The new firmware only solves some problems, but does not mean we can run ML on the 1300D.
I would have liked to be able to run ML, but it still has not succeeded (at least I can't) to solve the problem reported in the link above.
Maybe @a1ex can make a little time and help us, we can overcome this hop.
The same problem is with 2000D, 3000D, 4000D ...
Quote from: a1ex on July 17, 2018, 01:53:44 PM
This one is hard to fix - branch instructions in ARM code cannot go "too far" (they are limited to +/- 32MB around the address of the branch instruction). Normally, the compiler takes care of this (e.g. by using long jumps or inserting veneers - intermediate jumps), but here we are patching existing binary code in the firmware, to jump to our code instead.
I couldn't find an easy fix for this one; while a long jump can be implemented, it may require patching 2 instructions for one function. It's doable though, and other cameras will benefit from this (60D, which has the same problem in some experimental branches, and maybe some newer models too).
On 1300D I'm afraid we can't just use the workaround for 60D (where we load ML at a different address in order to be able to patch things), so a proper fix will be required in order to get some useful debug logs.
Quote from: a1ex on January 28, 2019, 12:56:47 PM
I'll try, but the solution is not straightforward.
Previously covered in replies #120 and #239.
Edit: confirmed the dm-spy-experiments branch is not working, even with minimal logging options (dm_spy_extra* commented out).
Need to use a long jump for patching DebugMsg. It started to work - to some extent - with this:
int err = patch_instruction(DebugMsg_addr, MEM(DebugMsg_addr), FAR_CALL_INSTR, "dm-spy: log all DebugMsg calls");
err |= patch_instruction(DebugMsg_addr + 4, MEM(DebugMsg_addr + 4), &my_DebugMsg, "dm-spy: log all DebugMsg calls");
The semaphore error appears to come from beep() - somebody's calling that before beep_init. Disabled beeps, it went further.
When trying to save the log, it fails with:
[dm-spy] captured 128kB of messages
[NotifyBox] Pretty-printing... (128kB)
[ CtrlSrv:fe49c7fc ] (83:02) DlgShootOlc.c LOCAL_DIALOG_REFRESH
qemu: fatal: Trying to execute code outside RAM or ROM at 0x87274218
That was because I've patched two instructions from DebugMsg, to implement the long call, but when uninstalling the logging hook, I should have "unpatched" both instructions. Rookie mistake.
Now, the hard part - clean up the code and commit it :D
Still need to find a general solution for patching arbitrary functions in Canon code (i.e. to implement long jump support in the patch manager).
The firmware is located at the end, and ends at 0xFFFFFFFF
What happens if you try to jump over 0xFFFFFFFF (relative), do the address wrap into 0xxxxxxx ram ? (or do we get an exception, possibly yes ?)
But if we dont get an exception - we could steal the first useable location in ram and make patch_instruction/gdb call this ram
function (using a single branch relative instruction). Then we could let this function analyze the lr and jump to the correct
location based on the lr value. This also requires that patch_instructions/gdb make a table of pc/lr's and where to jump to / jump back to
Quote from: critix on March 31, 2020, 10:40:01 AM
We still do not need the FIR file for bootflag.
We must first solve the problems for this device.
Read:
https://www.magiclantern.fm/forum/index.php?topic=17969.msg211084#msg211084 (https://www.magiclantern.fm/forum/index.php?topic=17969.msg211084#msg211084)
The new firmware only solves some problems, but does not mean we can run ML on the 1300D.
I would have liked to be able to run ML, but it still has not succeeded (at least I can't) to solve the problem reported in the link above.
Maybe @a1ex can make a little time and help us, we can overcome this hop.
The same problem is with 2000D, 3000D, 4000D ...
You've told me before Alex was necessary to solve this - now he may not be, just that he's currently the only one here who has the known how to?
Quote from: alawiggle on March 31, 2020, 05:54:40 PM
You've told me before Alex was necessary to solve this - now he may not be, just that he's currently the only one here who has the known how to?
Wise words from Walter Schulz
Quote from: Walter Schulz on February 12, 2020, 07:09:46 PM
Unicorn level: A person skilled with C, assembler and reverse engineering embedded devices (ARM architecture) with lots of free time at hand.
People with thsee skills (including myself) have wife, kids, boats, dogs, cats and a job and a lots of hobbies, amongst those one called ML. Guess the priority .. :o
Quote from: heder on March 31, 2020, 06:35:56 PM
Wise words from Walter Schulz
People with thsee skills (including myself) have wife, kids, boats, dogs, cats and a job and a lots of hobbies, amongst those one called ML. Guess the priority .. :o
Yes, I understand and I get it - but I was told that, specifically, Alex was the *only* one that could move this particular project forward. Now it seems this may not be the case? I'm just trying to determine if this is doable by somebody other than him. I understood that he had some "key" or some sort to the Canon firmware that was needed.
Quote from: alawiggle on April 06, 2020, 03:03:53 AM
Yes, I understand and I get it - but I was told that, specifically, Alex was the *only* one that could move this particular project forward. Now it seems this may not be the case? I'm just trying to determine if this is doable by somebody other than him. I understood that he had some "key" or some sort to the Canon firmware that was needed.
Hes not the only one, but there are only a few of us with the rigth skills and time. Ok, I will take a look later this month, and try to get qemu running with a modifed patch instruction. My Main focus is however 40d.
First issue is getting qemu to run then later the bootflag issue., But i cant solve the last as i dont own that camera.
If you can help us with modifying patch instruction so we can start in qemu. I have 1300D and I want to continue with this project.
Thank you.
Hello, i am new on this forum, so tbh i dont anythink about ml, but i have 1300d and i want help with project
Your coding skills?
Quote from: Walter Schulz on April 09, 2020, 03:55:50 PM
Your coding skills?
I dont have any coding skills so I am usseles?
ATM: Yes.
But if you are able to invest several hundred hours of work into learning it: No.
Hello, I have a Canon EOS Rebel T6 / 1300D and am willing to help out. If I have to learn stuff before starting, can someone please give me some tips and a place to look? Neat!
Visit autoexec_bin Twitter account and the sticky tweet there. Use ROM dumper to get a ... well ... ROM dump.
can we brick camera with this?
By using QEMU?
yea
https://en.wikipedia.org/wiki/Emulator
https://en.wikipedia.org/wiki/QEMU
Hey!
I own the 1300D and I really want to get hold of this firmware for a few upcoming projects. I have almost no idea about what's going on here and I don't think I could be of much help, but I wanna know if it's usable on the canon 1300d yet and if someone could point me in the right direction.
Thanks in advance
Brief update.
I promised somewere around april to look into the patch_instruction / cache_fake issue, but was delayed because I could'nt get the 40D raw module running correctly, and after critix reminded my a few times, I have started to look in this issue.
It possible to solve the general patch instruction issue for 1300D, but the problem is more general and the optimal solution is if we can get a solution that works for all cameras. I guess that is why the more simple cache_fake evolved into the patch_manager. Different cpu requires different tricks and hack to cope with our demands.
The issue that is annoying us is that normally we could change one single jump instruction into a new jumping instruction that could end up in our code, but due to the 32MB ROM layout that is not longer possible. Hijacking a complete function works fine with a1ex double patch instruction because when we hijack the complete function we have multiple instruction that we can change, but the problem is when we change a single instruction inside a function into a jump, or hijacking a jump inside a function to jump somewere else, when we fail because we can only jump +/- 32MB.
There are around two major solution to this problem, hard ones and perhaps a easy one. The hard one will allow us to use two instruction patch and thereby overwriting one additional instruction, and to avoid a crash, we would have to jump to a hook function then call the new funtion and afterward take into account (recode) the overwritten instruction. If we were hijacking a complete function fixup (recoding) would not be nessesary. Coding this => not me.
The easy solution is jumping multiple jumps, works fine, tested it. Each jump can to +/- 32MB, so two jumps and we're +/-64MB, then 1300D will work out just fine, should also work just fine with all other cameras. This one however requires that we can allocate a small ammount of memory (to store the 2nd jump instruction) within +/-32MB from ROM layout. I tried to use the ITCM area on the 500D (1300d branch) but that was a failure, because the 500D seems to uses that area, so other cameras may fail aswell. But looking at the memory layout it seems like 1300D malloc's has it first avilable memory is 0xBF408, see Reply #251. The ROM layout starts at 0xFE0C0000, which means we can jump anywere from ROM and below 0xC0000 (garanteed), and that solves the issue. Solution is to reserve a few bytes from 0xBF408 and use that as 2nd jumping table. Just need to code that.
Any comments, idea suggestions, yes, please.
Congratulations. I hope you succeed
with the code.
Quote from: critix on February 07, 2020, 12:22:43 PM
ML is not running on 1300D yet.
Boa tarde amigos!
Enquanto não sai o ML para a 1300D tem alguma forma de deixar a HDMI limpa neste equipamento?
Breif update.
I have been coding a new patch_instruction_jump function specific for jumps, (jump above +/- 32 MB address range) that uses multiple jumps. It's not complete yet, but now its holiday :) so I'm off programming the next two weeks. Still need to allocate memory correctly and I also have some troubles making my second jump into a absolute jump, LDR PC, [PC,offset] crashes for some unknown reasons. These tests does not jump above 32 MB, but so far only verifies that multiple jumps are working as intended.
Here is a output from my lastest test in QEMU (500D.111):
============================================
======== Memory before patching =======
============================================
failure_stubs1 addr 4da4c (e92d4008)
failure_stubs2 addr 4da30 (e92d4008)
failure_stubs3 addr 4da14 (e92d4008)
failure_stubs4 addr 4d9f8 (e92d4008)
failure_stubs5 addr 4d9e0 (e92d4008)
failure_stubs6 addr 4d9c8 (e92d4008)
success_stubs addr 4d9b0 (e92d4008)
============================================
= Testing cache_fake (QEMU ROM patching) =
============================================
* calling failure_stub1, return value expected (1000) actual = 1000
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub1, return value expected (1) actual = 1
* Test was a success
============================================
= Testing MEM(data) (QEMU ROM patching) =
============================================
* calling failure_stub2, return value expected (1001) actual = 1001
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub2, return value expected (1) actual = 1
* Test was a success
============================================
= Simple double jump (relative) hardcoded =
============================================
* calling failure_stub3, return value expected (1002) actual = 1002
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub3, return value expected (1) actual = 1
* Test was a success
============================================
= Simple double jump: =
= patch_instruction + MEM(data) patch =
============================================
* calling failure_stub4, return value expected (1003) actual = 1003
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub4, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (double rel jump) =
============================================
* calling failure_stub5, return value expected (1004) actual = 1004
* calling success_stub , return value expected (1) actual = 1
* using jump_vector 0 (address 9895e4)
* patching (re-route failure stub to success stub)
* calling failure_stub5, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (single rel jump) =
============================================
* calling failure_stub6, return value expected (1005) actual = 1004
* calling success_stub , return value expected (1) actual = 1
* patching (re-route failure stub to success stub)
* calling failure_stub6, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (double abs jump) =
= This test is missing =
============================================
============================================
= malloc versus stack versus static =
= This test is missing =
============================================
============================================
======== Memory after patching =======
============================================
failure_stubs1 addr 4da4c (eaffffd7)
failure_stubs2 addr 4da30 (eaffffde)
failure_stubs3 addr 4da14 (ea01ea43)
failure_stubs4 addr 4d9f8 (ea01ea4a)
failure_stubs5 addr 4d9e0 (ea24eeff)
failure_stubs6 addr 4d9c8 (eafffff8)
success_stubs addr 4d9b0 (e92d4008)
============================================
============ Done ==========================
============================================
Quote from: heder on June 11, 2020, 02:38:37 PM
Brief update.
(Lots elided!)
Solution is to reserve a few bytes from 0xBF408 and use that as 2nd jumping table. Just need to code that.
I must say, that was NOT a "brief" update :)
I'm very pleased to see that an understanding of the nature of the problem has emerged, as well as the general shape of a solution. Oh, my, jump tables :) :) :)
It is especially pleasing that this seems likely to help other cameras too.
You guys have all my support!
I wish I could help you, I wish you the best.
Hello :)
Help needed
I now have alternative patch_instruction called patch_instruction_jump running using a jump table which utilizes the
FAR_CALL trampoline. I have reserved room for 16 far call jumps, and I'm searching for people who are ready to test
and verify this in the QEMU. These tests verify that the cache hijack tricks are working as intended.
Requirements:
Due to bitbucket is closing down the test process is abit different than normally.
1. Download 1300d branch (https://bitbucket.org/hudson/magic-lantern/branch/1300D)
2. Overwrite some files from https://github.com/jmheder/ml/raw/master/update.zip (patch.c,patch.h,init.c,boot-hack.h)
3. make autoexec.bin (other targets will properly fail and is not needed anyway)
4. run _ONLY_ in QEMU (update autoexec.bin in sd.img/cf.img)
5. Post the console output from start until :
============================================
============ Done ==========================
============================================
Output result from 500d
Lockdown read 1
Lockdown read 1
Lockdown read 0
Lockdown read 0
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
Lockdown read 5
Lockdown read 5
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: eos.ram_uncached
F8000000 - F8FFFFFF: eos.rom1
F9000000 - F9FFFFFF: eos.rom1_mirror
FA000000 - FAFFFFFF: eos.rom1_mirror
FB000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FCFFFFFF: eos.rom1_mirror
FD000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FEFFFFFF: eos.rom1_mirror
FF000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.mmio
[EOS] loading './500D/ROM1.BIN' to 0xF8000000-0xF8FFFFFF
[MPU] warning: non-empty spell #9 (PROP_CARD2_STATUS) has duplicate(s): #39
[MPU] Available keys:
- Arrow keys : Navigation
- [ and ] : Main dial (top scrollwheel)
- SPACE : SET
- DELETE : guess (press only)
- M : MENU (press only)
- P : PLAY (press only)
- I : INFO/DISP (press only)
- L : LiveView (press only)
- A : Av
- Z/X : Zoom in/out
- Shift : Half-shutter
- 0/9 : Mode dial (press only)
- V : Movie mode (press only)
- B : Open battery door
- C : Open card door
- F10 : Power down switch
- F1 : show this help
Setting BOOTDISK flag to FFFFFFFF
FFFF23C8: MCR p15,0,Rd,cr6,cr0,0: 946_PRBS0 <- 0x3F (00000000 - FFFFFFFF, 0x100000000)
FFFF23D0: MCR p15,0,Rd,cr6,cr1,0: 946_PRBS1 <- 0x3D (00000000 - 7FFFFFFF, 0x80000000)
FFFF23D8: MCR p15,0,Rd,cr6,cr2,0: 946_PRBS2 <- 0xE0000039 (E0000000 - FFFFFFFF, 0x20000000)
FFFF23E0: MCR p15,0,Rd,cr6,cr3,0: 946_PRBS3 <- 0xC0000039 (C0000000 - DFFFFFFF, 0x20000000)
FFFF23E8: MCR p15,0,Rd,cr6,cr4,0: 946_PRBS4 <- 0xFF00002F (FF000000 - FFFFFFFF, 0x1000000)
FFFF23F0: MCR p15,0,Rd,cr6,cr5,0: 946_PRBS5 <- 0x39 (00000000 - 1FFFFFFF, 0x20000000)
FFFF23F8: MCR p15,0,Rd,cr6,cr6,0: 946_PRBS6 <- 0xF780002D (F7800000 - F7FFFFFF, 0x800000)
FFFF2400: MCR p15,0,Rd,cr2,cr0,0: DCACHE_CFG <- 0x70
FFFF2408: MCR p15,0,Rd,cr3,cr0,0: DACR <- 0x70
FFFF240C: MCR p15,0,Rd,cr2,cr0,1: ICACHE_CFG <- 0x70
FFFF2410: MCR p15,0,Rd,cr5,cr0,0: DATA_AP <- 0x3FFF
FFFF2418: MCR p15,0,Rd,cr5,cr0,1: INSN_AP <- 0x3FFF
FFFF241C: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0x2078
FFFF241C: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC000307D
FFFF05F0: MCR p15,0,Rd,cr9,cr1,1: ITCM <- 0x6 (00000000 - 00000FFF, 0x1000)
FFFF0604: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC000307D
FFFF0604: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC004307D
FFFF062C: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC004307D
FFFF062C: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC004107D
FFFF0640: MCR p15,0,Rd,cr9,cr1,0: DTCM <- 0x40000006 (40000000 - 40000FFF, 0x1000)
FFFF0648: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC004107D
FFFF0648: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC005107D
SD: CMD12 in a wrong state
[SDIO] Error
SD: CMD12 in a wrong state
[SDIO] Error
CF LOAD OK.
Open file for read : AUTOEXEC.BIN
SD: CMD12 in a wrong state
[SDIO] Error
SD: CMD12 in a wrong state
[SDIO] Error
Total_size=7DC60
Now jump to AUTOEXEC.BIN!!
0010AA80: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC005107D
0010AA80: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC005107D
0010A954: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
0087D61C: MCR p15, ... : CACHEMAINT x770 (omitted)
0087D61C: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
[boot] copy_and_restart 0x4d000 (315392)
[BOOT] changing user_mem_start from 0x4c5c4 (312772) to 0xdea40 (911936)
[BOOT] changing init_task from 0xff011dbc (-16704068) to 0x4d3dc (316380)
[BOOT] expecting armlib to overwrite A44C4: 9A000088 (task id 20002)
[BOOT] autoexec.bin loaded at 4D000 - DEA40.
[BOOT] calling pre_init_task 4E550...
[BOOT] installing task dispatch hook at 0x1934 (6452)
[BOOT] reserved 596544 bytes for ML (used 596544)
[BOOT] starting init_task 12BEFC...
K252 READY
[BOOT] A44C4 now contains 0, restoring 9A000088.
[BOOT] calling post_init_task 4E5B4...
[****] Starting task ff07102c(0) EvShel
[****] Starting task ff014ecc(0) ConsoleSvr
Open Console K252[1]>...
K252[1]>[****] Starting task ff0292cc(302430) Startup
[****] Starting task ff013580(0) Startup
[DMA1] Copy [0xF8A00000] -> [0x40304800], length [0x00196794], flags [0x00030001]
[DMA1] OK
[DMA2] Copy [0xF8910000] -> [0x405C4A00], length [0x000323DC], flags [0x00030001]
[DMA2] OK
[****] Starting task ff01563c(0) LowConsole
[****] Starting task ff1a67b0(302174) DbgMgr
[DMA2] Copy [0xF88F7000] -> [0x40604C00], length [0x00000864], flags [0x00030001]
[DMA2] OK
[DMA2] Copy [0xF89B0000] -> [0x40605E00], length [0x0000F3BC], flags [0x00030001]
[DMA2] OK
[DMA2] Copy [0xF8EB0000] -> [0x40626000], length [0x00008DDC], flags [0x00030001]
[DMA2] OK
[****] Starting task ff1a67b0(65827c) PropMgr
[MPU] Received: 06 04 02 00 00 00 (Init - spell #1)
[MPU] Sending : 0a 08 03 2f 00 00 00 00 00 00 (PROP_SPECIAL_OPTION)
[MPU] Sending : 06 05 01 37 00 00 (PROP_CARD_EXTENSION)
[MPU] Sending : 08 07 01 33 00 00 00 00 (PROP 80000029)
[MPU] Sending : 14 12 02 04 0d 01 01 00 02 00 00 03 00 00 00 00 00 00 00 00 (PROP_CFN)
[MPU] Sending : 06 05 01 20 00 00 (PROP_CARD1_EXISTS)
[MPU] Sending : 06 05 01 21 01 00 (PROP_CARD2_EXISTS)
[MPU] Sending : 06 05 01 22 00 00 (PROP_CARD3_EXISTS)
[MPU] Sending : 06 05 03 0c 00 00 (PROP_CARD1_RECORD)
[MPU] Sending : 06 05 03 0d 01 00 (PROP_CARD2_RECORD)
[MPU] Sending : 06 05 03 0e 01 00 (PROP_CARD3_RECORD)
[MPU] Sending : 08 06 01 23 00 01 00 00 (PROP_CARD1_STATUS)
[MPU] Sending : 08 06 01 24 00 00 00 00 (PROP_CARD2_STATUS)
[MPU] Sending : 08 06 01 25 00 00 00 00 (PROP_CARD3_STATUS)
[MPU] Sending : 06 05 01 2e 01 00 (PROP_SAVE_MODE)
[MPU] Sending : 06 05 01 37 00 00 (PROP_CARD_EXTENSION)
[MPU] Sending : 06 05 01 2c 02 00 (PROP_CURRENT_MEDIA)
[MPU] Sending : 06 05 03 20 00 00 (PROP_STARTUP_CONDITION)
[MPU] Sending : 06 05 01 42 00 00 (PROP_PHOTO_STUDIO_MODE)
[MPU] Sending : 06 05 01 43 00 00 (PROP 80040017)
[MPU] Sending : 06 05 01 44 00 00 (PROP 80040018)
[MPU] Sending : 06 05 01 46 00 00 (PROP_PHOTO_STUDIO_ENABLE_ISOCOMP)
[MPU] Sending : 06 05 01 48 01 00 (PROP_LIVE_VIEW_MOVIE_SELECT)
[MPU] Sending : 06 05 01 49 01 00 (PROP_LIVE_VIEW_AF_SYSTEM)
[MPU] Sending : 06 05 01 4b 01 00 (PROP_LIVE_VIEW_VIEWTYPE_SELECT)
[MPU] Sending : 08 06 01 47 0a 02 00 00 (PROP_SELFTIMER_CONTINUOUS_NUM)
[MPU] Sending : 06 05 03 37 00 00 (PROP_MIRROR_DOWN_IN_MOVIE_MODE)
[MPU] Sending : 2c 2a 02 00 03 03 03 00 03 00 00 48 01 00 00 0a 8c 00 00 00 00 83 06 00 00 04 06 00 00 04 06 00 00 04 01 00 00 00 00 00 58 24 aa 00 (Init group)
[****] Starting task ff1a67b0(65cd48) EventMgr
[MPU] Sending : 06 05 03 04 00 00 (PROP_POWER_KIND)
[MPU] Sending : 06 05 03 05 01 00 (PROP_POWER_LEVEL)
[MPU] Sending : 1e 1c 03 30 1b 1b 21 65 65 65 47 65 10 3a 10 3a 10 3a 00 1d 00 1d 00 1d 00 1d 00 00 00 00 (PROP 8003002A)
[MPU] Sending : 06 05 01 38 00 00 (PROP 80040005)
[MPU] Sending : 06 05 01 39 00 00 (PROP 80040006)
[MPU] Sending : 0c 0b 01 0a 00 79 00 00 00 00 00 00 (PROP_AFPOINT)
[MPU] Sending : 0e 0c 03 2e 00 00 22 81 00 00 26 89 00 00 (PROP_SHUTTER_COUNTER)
[MPU] Sending : 0a 08 03 2f 00 00 00 00 00 00 (PROP_SPECIAL_OPTION)
[MPU] Sending : 06 05 03 23 01 00 (unnamed)
[MPU] Sending : 06 05 03 24 00 00 (PROP_LENS_NAME)
[MPU] Sending : 06 04 03 25 00 00 (unnamed)
[MPU] Sending : 08 06 01 45 00 10 00 00 (PROP_METERING_TIMER_FOR_LV)
[MPU] Received: 08 06 00 00 02 00 00 00 (Complete WaitID = 0x80000001 Init - spell #2)
[MPU] Sending : 06 05 01 09 00 00 (PROP_FEC)
[MPU] Sending : 06 05 01 0d 00 00 (PROP_WB_MODE_PH)
[MPU] Sending : 06 05 01 3e 00 00 (PROP_ELECTRIC_SHUTTER_MODE)
[MPU] Sending : 06 05 01 3f 00 00 (PROP_FLASH_ENABLE)
[MPU] Sending : 06 05 01 40 00 00 (PROP_STROBO_ETTLMETER)
[MPU] Sending : 06 05 01 41 00 00 (PROP_STROBO_CURTAIN)
[****] Starting task ff1a67b0(65d32c) FileMgr
[****] Starting task ff1a67b0(77db1c) FileCache
[****] Starting task ff1a67b0(77dddc) RscMgr
[MPU] Received: 0a 08 03 06 00 00 00 00 00 00 (PROP_AVAIL_SHOT - spell #3)
[MPU] Received: 06 04 03 10 00 00 (PROP 80030008 - spell #4)
[MPU] Received: 06 05 03 07 ff 00 (PROP_BURST_COUNT - spell #5)
[MPU] Received: 06 05 01 2e 01 00 (PROP_SAVE_MODE - spell #6)
[MPU] Sending : 06 05 01 2e 01 00 (PROP_SAVE_MODE)
[MPU] Received: 0a 08 03 0b 00 00 00 00 00 00 (PROP 80030007 - spell #7)
[****] Starting task ff1a5e0c(781340) ShootCapture
[****] Starting task ff1a5e0c(7c2a4c) ShootBlack
[EDMAC#3] Starting transfer to 0x1FF0000 from <0>, 32x2048, flags=0x0
[CAPTURE] FIXME: what should we do here?
[EDMAC#3] 65536 bytes written to 1FF0000-2000000.
[EDMAC#3] transfer delay 1 x 256 us.
[EDMAC#10] Starting transfer from 0x61425C to <8>, 2000x1000, flags=0x20000
[EDMAC#10] 2000000 bytes read from 61425C-7FC6DC.
[EDMAC#10] transfer delay 38 x 256 us.
[ADKIZ] Data unavailable; will try again later.
[HIV] Data unavailable; will try again later.
[EDMAC#11] Starting transfer from 0x431C64 to <15>, 2000x1000, flags=0x40000
[EDMAC#11] 2000000 bytes read from 431C64-61A0E4.
[EDMAC#11] transfer delay 38 x 256 us.
[ADKIZ] Dummy operation.
[HIV] Data unavailable; will try again later.
[EDMAC#3] Starting transfer to 0x1FE0000 from <0>, 32x2048, flags=0x0
[CAPTURE] FIXME: what should we do here?
[EDMAC#3] 65536 bytes written to 1FE0000-1FF0000.
[EDMAC#3] transfer delay 1 x 256 us.
[EDMAC#10] Starting transfer from 0x61465C to <8>, 2000x1000, flags=0x20000
[EDMAC#10] 2000000 bytes read from 61465C-7FCADC.
[EDMAC#10] transfer delay 38 x 256 us.
[ADKIZ] Data unavailable; will try again later.
[HIV] Data unavailable; will try again later.
[EDMAC#11] Starting transfer from 0x414DDC to <15>, 2000x1000, flags=0x40000
[EDMAC#11] 2000000 bytes read from 414DDC-5FD25C.
[EDMAC#11] transfer delay 38 x 256 us.
[ADKIZ] Dummy operation.
[HIV] Data unavailable; will try again later.
[****] Starting task ff1a5e0c(7c2e54) ShootPreDevelop
[****] Starting task ff020828(0) MainCtrl
[MPU] Received: 06 05 04 0e 01 00 (PROP 8002000D - spell #8)
[****] Starting task ff1a5e0c(7c31ec) TOMgr
[****] Starting task ff1a5e0c(7c4380) Fstorage
[****] Starting task ff064b28(0) DOSDriver
[****] Starting task ff329c04(0) CSMgrTask
[****] Starting task ff01dccc(0) HotPlug
0: 51.968 [STARTUP]
K252 ICU Firmware Version 1.1.1 ( 3.6.4 )
42: 162.304 [RSC] PROP_IMG_VRAM_OFFSET = 30720
43: 162.560 [RSC] AllocateMemoryUnit For ExMem1
44: 162.560 [RSC] AllocateMemoryUnit For ExMem1_2
64: 215.552 [RSC] this->MovSize = 0
86: 266.240 [ENG] [ENGIO](Addr:0x4ff80000, Data:0x 30000)
87: 287.232 [CAPE] FIRM TYPE:::DD_B
111: 314.112 [SHTB] LV PDEF MERGE DONE
113: 316.672 [FM] FM_RegisterSpaceNotifyCallback
116: 317.952 [FM] FM_RegisterSpaceNotifyCallback
138: 337.408 [MC] PROP_GUI_STATE 0
143: 338.688 [MC] JobState 0
144: 339.712 [MC] HDMIConnect ---> (0)
148: 344.576 [MC] regist master CardCover
[****] Starting task ff1a293c(0) PowerMgr
SD: Unknown CMD1
[SDIO] Error
SD: Unknown CMD1
[SDIO] Error
SD: Unknown CMD1
[SDIO] Error
163: 588.800 [SD] ERROR SDINTREP=0x00000000
164: 589.056 [SD] ERROR UNEXPECTED ERROR
[MPU] Received: 08 06 01 24 00 01 00 00 (PROP_CARD2_STATUS - spell #9)
[MPU] Sending : 08 06 01 24 00 01 00 00 (PROP_CARD2_STATUS)
[MPU] Received: 08 06 01 27 00 64 00 00 (PROP_CARD2_FOLDER_NUMBER - spell #10)
[MPU] Received: 06 05 03 07 07 00 (unknown - PROP_BURST_COUNT)
[MPU] Received: 0a 08 03 06 00 00 00 07 00 00 (unknown - PROP_AVAIL_SHOT)
[MPU] Received: 08 07 01 2a 20 ae 00 00 (PROP_CARD2_FILE_NUMBER - spell #13)
[MPU] Received: 06 05 03 11 01 00 (PROP_ICU_AUTO_POWEROFF - spell #14)
[MPU] Received: 06 05 02 0a 00 00 (PROP_PERMIT_ICU_EVENT - spell #15)
[MPU] Sending : 06 05 03 37 00 00 (PROP_MIRROR_DOWN_IN_MOVIE_MODE)
[MPU] Sending : 0a 08 03 00 4a 00 00 01 00 00 (PROP 80030000)
[MPU] Received: 06 05 03 0d 00 00 (PROP_CARD2_RECORD - spell #16)
[MPU] Received: 06 05 03 0c 00 00 (PROP_CARD1_RECORD - spell #17)
[MPU] Sending : 14 12 03 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (PROP_LENS)
[****] Starting task ff1a5e0c(840778) FrontShtDevelop
[MPU] Sending : 06 05 03 17 9a 00 (PROP_EFIC_TEMP)
[MPU] Sending : 06 05 03 0d 00 00 (PROP_CARD2_RECORD)
[****] Starting task ff1a5e0c(8409cc) RearShtDevelop
[MPU] Sending : 06 05 03 0c 00 00 (PROP_CARD1_RECORD)
[****] Starting task ff023998(0) GuiLockTask
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #18)
190: 693.248 [RSC] AddExMem1UnitToShootMemoryObject
210: 709.888 [PRP] M:4A F:0 L:0 P:1
[****] Starting task ff05326c(0) ASIF
[****] Starting task ff1a67b0(85f724) MovWriter
[****] Starting task ff1a67b0(85f988) MovieRecorder
[****] Starting task ff1a67b0(85facc) LVC_AE
[****] Starting task ff1a67b0(8604e0) LVC_AF
[****] Starting task ff1a67b0(865794) LVC_DEV
[****] Starting task ff1a67b0(8658f8) LVC_MD
[****] Starting task ff037ed8(0) LVC_FACE
[****] Starting task ff1a67b0(868130) LiveViewMgr
[MPU] Received: 06 05 09 11 01 00 (PROP_LV_DISPSIZE - spell #19)
[MPU] Received: 08 06 03 18 00 00 00 00 (PROP 8003000F - spell #20)
[MPU] Received: 08 06 03 1f 00 00 00 00 (PROP 80030019 - spell #21)
[MPU] Received: 06 05 03 13 00 00 (PROP_LOGICAL_CONNECT - spell #22)
[MPU] Received: 06 05 03 1e 00 00 (PROP 8003001A - spell #23)
[****] Starting task ff0549e8(0) SoundDevice
[****] Replacing task ff0549e8 with 80a44
[****] Starting task ff1a5e0c(86a4c0) DiUSB20Drv
[****] Starting task ff1a5e0c(86b374) Remote
[****] Starting task ff104c38(0) USBTrns
[****] Starting task ff10e88c(0) SDIOTrns
[****] Starting task ff20b714(86c904) PTPSessionTASK
[****] Starting task ff1a5e0c(86d6c8) PtpDps
[****] Starting task ff1a5e0c(89e008) Fcreate
[****] Starting task ff1a67b0(86829c) LiveViewAngelMgr
[****] Starting task ff1a5e0c(89f42c) Fread
[****] Starting task ff14a38c(0) AviRead
[****] Starting task ff1468d8(0) MovRead
[****] Starting task ff048390(0) MoviePlay
[****] Starting task ff061a70(0) TftRecover
[****] Starting task ff062f34(0) HDMI
[****] Starting task ff022a9c(0) GuiMainTask
[****] Replacing task ff022a9c with 5bd10
[****] Starting task ff18ab40(0) CtrlSrv
[****] Starting task ff175370(0) ImgPlayDrv
[****] Starting task ff1a67b0(8b6484) ReDevelop
[****] Starting task ff1a67b0(8b6528) DpMgr
[****] Starting task ff0cd2b4(0) DpsReceiveTask
[****] Starting task ff1a67b0(8b83c8) DpImgEditMgr
[****] Starting task ff05ea28(0) EyeFi
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #24)
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #25)
[MPU] Received: 06 05 02 0a 01 00 (PROP_PERMIT_ICU_EVENT - spell #26)
[MPU] Sending : 42 41 0a 08 ff 1f 01 00 01 03 98 10 00 58 01 01 00 00 00 01 01 00 48 04 01 00 15 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (PD_NotifyOlcInfoChanged)
[MPU] Sending : 06 05 06 11 01 00 (GUI_SWITCH)
[MPU] Sending : 06 05 06 12 00 00 (GUI_SWITCH)
[MPU] Sending : 06 05 06 13 00 00 (GUI_SWITCH)
[MPU] Sending : 06 05 06 1c 00 00 (GUI_SWITCH)
[****] Starting task ff1e22f0(0) PTPtoFAPI_EventProcTask
[****] Starting task ff1a5e0c(89f674) Fwrite
[****] Starting task ff1a67b0(8b606c) Mrk
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #31)
[****] Starting task ff08b160(0) LpfMode
234: 811.008 [LVAF] lvcafProperty(PROP_LV_AF_RESULT_MPU)
235: 811.264 [LVAF] lvcafProperty ID=0x80050029(0x0)
[BOOT] my_init_task completed.
======================================
= jump vector allocation =
======================================
jump-vector using malloc == 0xfc480 (1033344)
jump-vector alloca == 0x12bdf0 (1228272)
jump_vector_static == 0xd4800 (870400)
jump vector winner was static allocation
236: 818.432 [LVMD] Init RCh1=0, RCh2=0
239: 823.808 [LV] InitializeLiveViewDefectDetection
248: 832.512 [LVMD] Set RCh1=a, RCh2=19
250: 841.216 [LV] AE ModeDial=3
258: 849.152 [LVCFG] PROP_LV_ACTION STOP
259: 849.408 [LV] JudgeStartLV 0x1 0x0 0xFFFF 2 0 0 5138
262: 850.944 [LVCFG] PROP_LV_LOCK PERIMIT
263: 851.456 [LV] JudgeStartLV 0x1 0x1 0xFFFF 2 0 0 5145
266: 851.968 [LVCFG] PROP_SHOOTING_TYPE 0
267: 854.016 [LV] JudgeStartLV 0x1 0x1 0x0 2 0 0 5152
282: 861.184 [LV] MovieResolution=0
jump vector allocation doneLens moving (0, 0)
jump_vector - from boot.h = d4800
jump_vector - aligned = d4800
283: 861.696 [LVCFG] PROP_LIVE_VIEW_VIEWTYPE_SELECT 0->1
285: 862.208 [LVCFG] PROP_LIGHT_FALLOFF_COMP 0
313: 928.000 [FM] cnvMakerFocus_Alloc : Not Regist
315: 928.512 [FM] cnvMakerFocus_Free : Not Regist
396: 966.656 [PTPCOM] SetPtpTransportResources:0,31cf
478: 1027.840 [HDMI] HPD OFF
539: 1129.984 [LV] PROP_OUTPUT_TYPE(0) 9-0 1 0
589: 1183.488 [GUI] HDMI_VIDEO_CODE 0
625: 1263.104 [GUI] MainEventHndler PROP_MIRROR_DOWN_IN_MOVIE_MODE(0)
678: 1291.776 [STARTUP] startupInitializeComplete
680: 1293.312 [MC] cam event guimode comp. 0
698: 1304.576 [MC] cam event guimode comp. 0
723: 1331.200 [MC] notice Lock 1
[****] Starting task 4dbf8(0) ml_backup
[****] Starting task 55b94(0) menu_task
[****] Starting task 58854(0) menu_redraw_task
[****] Starting task 61b78(0) bitrate_task
[****] Starting task 6e1e0(0) focus_task
[****] Starting task 6f368(0) notifybox_task
[****] Starting task 71a88(0) fps_task
[****] Starting task 79ddc(0) shoot_task
[****] Starting task 75854(0) clock_task
[****] Starting task 80630(0) audio_common_task
[****] Starting task 87d34(0) livev_hiprio_task
[****] Starting task 866dc(0) cls_task
[****] Starting task 89858(0) beep_task
[****] Starting task 9622c(0) console_task
[****] Starting task 5add8(0) debug_task
[****] Starting task 643b0(0) tweak_task
[****] Starting task 6e920(0) focus_misc_task
[****] Starting task 7bd2c(0) vignetting_init
[****] Starting task 87524(0) livev_loprio_task
============================================
======== Camera modole 500D
======== Memory before patching =======
============================================
failure_stubs1 addr 4db2c (e92d4008)
failure_stubs2 addr 4db10 (e92d4008)
failure_stubs3 addr 4daf4 (e92d4008)
failure_stubs4 addr 4dadc (e92d4008)
failure_stubs5 addr 4dac0 (e92d4008)
failure_stubs6 addr 4daa4 (e92d4008)
failure_stubs7 addr 4da88 (e92d4008)
success_stubs addr 4da70 (e92d4008)
============================================
= Testing cache_fake (QEMU ROM patching) =
============================================
* calling failure_stub1, return value expected (1001) actual = 1001
* calling success_stub , return value expected (1) actual = 1
* patching using old patching method, (jump only few bytes) rerouting to succes_stubs (0)
* calling failure_stub1, return value expected (1) actual = 1
* Test was a success
============================================
= Testing MEM(data) (QEMU ROM patching) =
============================================
* calling failure_stub2, return value expected (1002) actual = 1002
* calling success_stub , return value expected (1) actual = 1
* patching done
* calling failure_stub2, return value expected (1) actual = 1
* Test was a success
============================================
= Simple double jump (relative) hardcoded =
============================================
* calling failure_stub3, return value expected (1003) actual = 1003
* calling success_stub , return value expected (1) actual = 1
* patching done
* calling failure_stub3, return value expected (1) actual = 1
* Test was a success
============================================
= Simple double jump: =
= patch_instruction + MEM(data) patch =
============================================
* calling failure_stub4, return value expected (1004) actual = 1004
* calling success_stub , return value expected (1) actual = 1
* patching done
* calling failure_stub4, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (double rel jump) =
============================================
* calling failure_stub5, return value expected (1005) actual = 1005
* calling success_stub , return value expected (1) actual = 1
* using jump_vector 0 (address d4800)
* double relative
* patching done
* calling failure_stub5, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (single rel jump) =
============================================
* calling failure_stub6, return value expected (1006) actual = 1006
* calling success_stub , return value expected (1) actual = 1
* patch_instruction = Using single jump
* patching done
* calling failure_stub6, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (rel+abs jump) =
= This is primary goal :) =
============================================
* calling failure_stub7, return value expected (1007) actual = 1007
* calling success_stub , return value expected (1) actual = 1
* using jump_vector 1 (address d480c)
* relative plus absolute (trampoline)
* patching done
* calling failure_stub7, return value expected (1) actual = 1
* Test was a success
============================================
======== Memory after patching =======
============================================
failure_stubs1 addr 4db2c (eaffffcf)
failure_stubs2 addr 4db10 (eaffffd6)
failure_stubs3 addr 4daf4 (ea01eb0b)
failure_stubs4 addr 4dadc (ea01eb11)
failure_stubs5 addr 4dac0 (ea021b4e)
failure_stubs6 addr 4daa4 (eafffff1)
failure_stubs7 addr 4da88 (ea021b5f)
success_stubs addr 4da70 (e92d4008)
============================================
============ Done ==========================
============================================
I will check and come back with results ...
Thanks
OK...results:
DebugMsg=0xFE11F394 (from GDB script)
Lockdown read 1
Lockdown read 1
Lockdown read 0
Lockdown read 0
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
Lockdown read 5
Lockdown read 5
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: eos.ram_uncached
F8000000 - F9FFFFFF: eos.rom1
FA000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.mmio
[EOS] loading './1300D/ROM1.BIN' to 0xF8000000-0xF9FFFFFF
[MPU] warning: non-empty spell #11 (PROP_CARD2_STATUS) has duplicate(s): #52
[MPU] warning: non-empty spell #20 (PROP_TFT_STATUS) has duplicate(s): #37 #38 #75
[MPU] warning: non-empty spell #35 (PROP_VIDEO_MODE) has duplicate(s): #36
[MPU] warning: non-empty spell #43 (PROP_TFT_STATUS) has duplicate(s): #41 #42 #44 #46
[MPU] Available keys:
- Arrow keys : Navigation
- [ and ] : Main dial (top scrollwheel)
- SPACE : SET
- DELETE : guess (press only)
- M : MENU (press only)
- P : PLAY (press only)
- I : INFO/DISP (press only)
- Q : guess (press only)
- L : LiveView (press only)
- A : Av
- Z/X : Zoom in/out
- Shift : Half-shutter
- 0/9 : Mode dial (press only)
- V : Movie mode (press only)
- B : Open battery door
- C : Open card door
- F10 : Power down switch
- F1 : show this help
Setting BOOTDISK flag to FFFFFFFF
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: ITCM <- 0x6 (00000000 - 00000FFF, 0x1000)
FFFF00CC: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC000307D
FFFF00CC: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC004307D
FFFF00D8: MCR p15,0,Rd,cr9,cr1,0: DTCM <- 0x40000006 (40000000 - 40000FFF, 0x1000)
FFFF00E0: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC004307D
FFFF00E0: 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
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x66580
Now jump to AUTOEXEC.BIN!!
00865F9C: MCR p15, ... : CACHEMAINT x770 (omitted)
00865F9C: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
00C80684: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
00C8068C: MCR p15,0,Rd,cr9,cr0,1: ILockDown <- 0x80000000
00C80694: MCR p15,0,Rd,cr9,cr0,1: ILockDown <- 0x1
00C8069C: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x0
00C806A0: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x20
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x20
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x40
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x40
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x60
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x60
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x80
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x80
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xA0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xA0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xC0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xC0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xE0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xE0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x100
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x100
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x120
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x120
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x140
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x140
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x160
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x160
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x180
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x180
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1A0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1A0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1C0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1C0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1E0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x1E0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x200
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x200
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x220
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x220
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x240
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x240
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x260
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x260
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x280
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x280
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2A0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2A0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2C0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2C0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2E0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x2E0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x300
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x300
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x320
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x340
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x340
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x360
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x380
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x380
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3A0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3A0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3C0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3C0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3E0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x3E0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x400
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x400
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x420
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x420
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x440
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x440
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x460
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x460
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x480
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x480
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4A0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4A0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4C0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4C0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4E0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x4E0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x500
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x500
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x520
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x520
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x540
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x540
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x560
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x560
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x580
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x580
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5A0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5A0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5C0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5C0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5E0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x5E0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x600
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x600
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x620
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x620
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x640
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x640
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x660
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x660
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x680
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x680
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6A0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6A0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6C0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6C0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6E0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x6E0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x700
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x700
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x720
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x720
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x740
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x740
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x760
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x760
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x780
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x780
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7A0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7A0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7C0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7C0
00C806AC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7E0
00C806A8: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0x7E0
00C806E8: MCR p15, ... : CACHEMAINT x256 (omitted)
00C80708: MCR p15,0,Rd,cr9,cr0,0: DLockDown <- 0x80000000
00C80710: MCR p15,0,Rd,cr9,cr0,0: DLockDown <- 0x1
00C80718: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x0
00C8071C: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x20
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x20
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x40
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x40
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x60
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x60
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x80
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x80
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xA0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xA0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xC0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xC0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0xE0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xE0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x100
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x100
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x120
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x120
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x140
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x140
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x160
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x160
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x180
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x180
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1A0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1A0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1C0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1C0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x1E0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x1E0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x200
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x200
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x220
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x220
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x240
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x240
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x260
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x260
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x280
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x280
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2A0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2A0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2C0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2C0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x2E0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x2E0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x300
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x300
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x320
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x340
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x340
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x360
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x380
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x380
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3A0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3A0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3C0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3C0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x3E0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x3E0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x400
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x400
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x420
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x420
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x440
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x440
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x460
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x460
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x480
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x480
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4A0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4A0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4C0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4C0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x4E0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x4E0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x500
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x500
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x520
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x520
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x540
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x540
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x560
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x560
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x580
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x580
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5A0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5A0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5C0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5C0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x5E0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x5E0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x600
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x600
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x620
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x620
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x640
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x640
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x660
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x660
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x680
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x680
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6A0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6A0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6C0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6C0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x6E0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x6E0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x700
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x700
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x720
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x720
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x740
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x740
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x760
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x760
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x780
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x780
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7A0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7A0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7C0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7C0
00C80728: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x7E0
00C80724: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0x7E0
00C80464: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
Lockdown read 2
00C80468: MRC p15,3,Rd,cr15,cr2,0: DcacheTag -> 0x0
00C803BC: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xFE129684
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x324
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE12FFF1E
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x328
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE92D400E
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x32C
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE59F0254
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x330
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE3A010FF
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x334
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE5CD1008
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x338
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE3A01000
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x33C
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xE58D0000
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x320
00C803C0: MCR p15,3,Rd,cr15,cr2,0: DcacheTag <- 0xFE0C3B30
00C803C4: MCR p15,3,Rd,cr15,cr4,0: DcacheVal <- 0xC8047C
Cache patch: [FE0C3B20] <- C8047C (was FE129684)
00C803F4: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
Lockdown read 1
00C803F8: MRC p15,3,Rd,cr15,cr1,0: IcacheTag -> 0x0
00C803A8: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x360
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE92D4010
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x364
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE24DD018
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x368
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE28F0F9A
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x36C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEBFFFDB5
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x370
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB015F44
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0160D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x378
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A0082D
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x37C
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xEB01960B
00C80390: MCR p15,3,Rd,cr15,cr0,0: CacheDbgIdx <- 0x374
00C803AC: MCR p15,3,Rd,cr15,cr1,0: IcacheTag <- 0xFE0C1B70
00C803B0: MCR p15,3,Rd,cr15,cr3,0: IcacheVal <- 0xE3A018C8
Cache patch: [FE0C1B74] <- E3A018C8 (was E3A0160D)
DRYOS PANIC: Module Code = 64, Panic Code = 1
Unfortunately ... DRYOS PANIC
Critix, it's working :D
I will post a reply later today with all the information needed to repeat this test and I will just sum up all the thing that you and I found and
write them down. I will write the way I got everything running, because there are more way to get everything running, and all the bits and
bytes needed are in many replies.
But for now just lets see and anaylze the output !
Output
heder@heder-Aspire-R3610:~/magic-root/repositories/unified/qemu-eos$ ./go_hijack_test_1300d.sh
Lockdown read 1
Lockdown read 1
Lockdown read 0
Lockdown read 0
Lockdown read 2
Lockdown read 2
Lockdown read 3
Lockdown read 3
Lockdown read 4
Lockdown read 4
Lockdown read 5
Lockdown read 5
00000000 - 00000FFF: eos.tcm_code
40000000 - 40000FFF: eos.tcm_data
00001000 - 0FFFFFFF: eos.ram
40001000 - 4FFFFFFF: eos.ram_uncached
F0000000 - F1FFFFFF: eos.rom0
F2000000 - F3FFFFFF: eos.rom0_mirror
F4000000 - F5FFFFFF: eos.rom0_mirror
F6000000 - F7FFFFFF: eos.rom0_mirror
F8000000 - F9FFFFFF: eos.rom1
FA000000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.mmio
[EOS] loading './1300D/ROM0.BIN' (expected size 0x02000000, got 0x0000000A) to 0xF0000000-0xF0000009
[EOS] loading './1300D/ROM1.BIN' to 0xF8000000-0xF9FFFFFF
[MPU] warning: non-empty spell #11 (PROP_CARD2_STATUS) has duplicate(s): #52
[MPU] warning: non-empty spell #20 (PROP_TFT_STATUS) has duplicate(s): #37 #38 #75
[MPU] warning: non-empty spell #35 (PROP_VIDEO_MODE) has duplicate(s): #36
[MPU] warning: non-empty spell #43 (PROP_TFT_STATUS) has duplicate(s): #41 #42 #44 #46
[MPU] Available keys:
- Arrow keys : Navigation
- [ and ] : Main dial (top scrollwheel)
- SPACE : SET
- DELETE : guess (press only)
- M : MENU (press only)
- P : PLAY (press only)
- I : INFO/DISP (press only)
- Q : guess (press only)
- L : LiveView (press only)
- A : Av
- Z/X : Zoom in/out
- Shift : Half-shutter
- 0/9 : Mode dial (press only)
- V : Movie mode (press only)
- B : Open battery door
- C : Open card door
- F10 : Power down switch
- F1 : show this help
Setting BOOTDISK flag to FFFFFFFF
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: ITCM <- 0x6 (00000000 - 00000FFF, 0x1000)
FFFF00CC: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC000307D
FFFF00CC: MCR p15,0,Rd,cr1,cr0,0: SCTLR <- 0xC004307D
FFFF00D8: MCR p15,0,Rd,cr9,cr1,0: DTCM <- 0x40000006 (40000000 - 40000FFF, 0x1000)
FFFF00E0: MRC p15,0,Rd,cr1,cr0,0: SCTLR -> 0xC004307D
FFFF00E0: 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
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x6FBA0
Now jump to AUTOEXEC.BIN!!
0086F55C: MCR p15, ... : CACHEMAINT x770 (omitted)
0086F55C: MCR p15,0,Rd,cr7,cr5,0: FlushICache <- 0x0
[boot] copy_and_restart 0xc80000 (13107200)
[BOOT] changing init_task from 0xfe1296c8 (-32336184) to 0xc80570 (13108592)
[BOOT] autoexec.bin loaded at C80000 - CFE180.
[BOOT] calling local pre_init_task C80380...
[BOOT] changing AllocMem end address: 0xd00000 (13631488) -> 0xc80000 (13107200)
0xfe0c1b74: e3a0160d mov r1, #13631488 ; 0xd00000
0xfe0c1b78: e3a0082d mov r0, #2949120 ; 0x2d0000
0xfe0c1b74: e3a018c8 mov r1, #13107200 ; 0xc80000
0xfe0c1b78: e3a0082d mov r0, #2949120 ; 0x2d0000
[BOOT] calling pre_init_task C81590...
[BOOT] installing task dispatch hook at 0x35924 (219428)
[BOOT] reserved 524288 bytes for ML (used 516480)
[BOOT] starting init_task 14B704...
K404 READY
[BOOT] calling local post_init_task C804EC...
[BOOT] uninstalling cache hacks...
[BOOT] calling post_init_task C815F4...
[****] Starting task fe0d3c68(2d2da0) Startup
[DMA1] Copy [0xF8E60000] -> [0x402D4000], length [0x0026BBF8], flags [0x00030001]
[DMA1] OK
[****] Starting task fe0c12ac(0) TaskMain
[****] Starting task fe2c2114(2d2ae4) DbgMgr
0: 12.544 [STARTUP]
K404 ICU Firmware Version 1.1.0 ( 4.4.6 )
[****] Starting task fe2bafd0(0) PowerMgr
[DMA1] Copy [0xF8D80000] -> [0x40584200], length [0x0007135C], flags [0x00030001]
[DMA1] OK
[DMA1] Copy [0xF8C20000] -> [0x40624300], length [0x00000F6C], flags [0x00030001]
[DMA1] OK
[DMA1] Copy [0xF8CE0000] -> [0x40625500], length [0x00016234], flags [0x00030001]
[DMA1] OK
[DMA1] Copy [0xF8C80000] -> [0x40645700], length [0x0001AEE8], flags [0x00030001]
[DMA1] OK
[****] Starting task fe2c2114(66a874) PropMgr
[MPU] Received: 06 04 02 00 00 00 (Init - spell #1)
[MPU] Sending : 06 05 01 00 03 00 (PROP_SHOOTING_MODE)
[MPU] Sending : 06 05 01 05 45 00 (PROP_SHUTTER)
[MPU] Sending : 06 05 01 06 5b 00 (PROP_APERTURE)
[MPU] Sending : 06 05 01 0b 00 00 (PROP_AEB)
[MPU] Sending : 2c 2a 02 00 03 03 03 00 03 00 00 00 00 00 00 12 5c 00 00 00 00 87 01 00 00 03 01 00 00 03 01 00 00 03 01 01 00 00 00 00 45 5b 01 00 (Init group)
[MPU] Sending : 08 07 01 33 09 00 00 00 (PROP 80000029)
[MPU] Sending : 06 05 01 20 00 00 (PROP_CARD1_EXISTS)
[MPU] Sending : 06 05 01 21 01 00 (PROP_CARD2_EXISTS)
[MPU] Sending : 06 05 01 22 00 00 (PROP_CARD3_EXISTS)
[MPU] Sending : 06 05 03 0c 01 00 (PROP_CARD1_RECORD)
[MPU] Received: 08 06 00 00 02 00 00 00 (Complete WaitID = 0x80000001 Init - spell #2)
[MPU] Sending : 06 05 03 0d 01 00 (PROP_CARD2_RECORD)
[MPU] Sending : 06 05 03 0e 01 00 (PROP_CARD3_RECORD)
[MPU] Sending : 08 06 01 23 00 01 00 00 (PROP_CARD1_STATUS)
[MPU] Sending : 08 06 01 24 00 00 00 00 (PROP_CARD2_STATUS)
[MPU] Sending : 08 06 01 25 00 01 00 00 (PROP_CARD3_STATUS)
[****] Starting task fe2c2114(6719b4) EventMgr
[MPU] Sending : 06 05 01 2e 01 00 (PROP_SAVE_MODE)
[MPU] Sending : 06 05 01 2c 02 00 (PROP_CURRENT_MEDIA)
[MPU] Sending : 06 05 03 20 01 00 (PROP_STARTUP_CONDITION)
[MPU] Sending : 06 05 01 3d 00 00 (PROP_TEMP_STATUS)
[MPU] Sending : 06 05 01 42 00 00 (PROP_PHOTO_STUDIO_MODE)
[MPU] Sending : 0c 0b 03 42 00 00 00 00 00 00 00 00 (PROP_LED_LIGHT)
[MPU] Sending : 0c 0b 01 0a 00 01 00 00 00 00 00 00 (PROP_AFPOINT)
[MPU] Sending : 06 05 01 37 00 00 (PROP_CARD_EXTENSION)
[MPU] Sending : 06 05 01 49 01 00 (PROP_LIVE_VIEW_AF_SYSTEM)
[MPU] Sending : 06 05 01 3e 00 00 (PROP_ELECTRIC_SHUTTER_MODE)
[MPU] Sending : 08 06 01 45 07 08 00 00 (PROP_METERING_TIMER_FOR_LV)
[****] Starting task fe2c2114(671f80) FileMgr
[MPU] Sending : 06 05 01 48 01 00 (PROP_LIVE_VIEW_MOVIE_SELECT)
[MPU] Sending : 06 05 01 4b 01 00 (PROP_LIVE_VIEW_VIEWTYPE_SELECT)
[MPU] Sending : 06 05 01 40 00 00 (PROP_STROBO_ETTLMETER)
[MPU] Sending : 06 05 01 41 00 00 (PROP_STROBO_CURTAIN)
[MPU] Sending : 06 05 01 3f 00 00 (PROP_FLASH_ENABLE)
[MPU] Sending : 08 06 01 57 00 01 00 00 (PROP_BUILTIN_STROBO_MODE)
[MPU] Sending : 1a 18 01 4e 00 00 00 00 00 00 00 00 00 00 00 1e 00 00 00 0f 00 00 00 00 00 00 (PROP_VIDEO_MODE)
[MPU] Sending : 06 05 01 48 01 00 (PROP_LIVE_VIEW_MOVIE_SELECT)
[MPU] Sending : 06 05 01 53 00 00 (PROP_SHUTTER_AF_DURING_RECORD)
[MPU] Sending : 06 05 01 58 00 00 (PROP_VIDEOSNAP_MODE)
[MPU] Sending : 06 05 01 59 00 00 (PROP_MOVIE_SERVO_AF)
[****] Starting task fe2c2114(79287c) FileCache
[MPU] Sending : 06 05 01 4a 00 00 (PROP_PROGRAM_SHIFT)
[MPU] Sending : 06 05 01 50 00 00 (PROP_AE_MODE_MOVIE)
[MPU] Sending : 08 06 01 51 78 48 00 00 (PROP_AUTO_ISO_RANGE)
[****] Starting task fe2c2114(792b8c) RscMgr
[MPU] Received: 1a 18 01 4e 00 00 00 00 00 00 00 00 00 00 00 19 00 00 00 0c 00 00 00 00 00 00 (unknown - PROP_VIDEO_MODE)
[MPU] Sending : 06 05 01 52 03 00 (PROP_ALO)
[MPU] Sending : 06 05 01 54 00 00 (PROP_SUBDIAL_LOCK_MODE)
[MPU] Sending : 08 06 01 47 0a 02 00 00 (PROP_SELFTIMER_CONTINUOUS_NUM)
[MPU] Sending : 06 05 03 37 00 00 (PROP_MIRROR_DOWN_IN_MOVIE_MODE)
[MPU] Sending : 12 11 02 04 00 00 01 00 00 03 00 00 00 00 00 00 00 00 (PROP_CFN)
[MPU] Received: 0a 08 03 06 00 00 00 00 00 00 (PROP_AVAIL_SHOT - spell #4)
[MPU] Received: 06 04 03 10 00 00 (PROP 80030008 - spell #5)
[MPU] Received: 06 05 03 07 ff 00 (PROP_BURST_COUNT - spell #6)
[MPU] Sending : 0e 0c 03 2e 00 00 29 7e 00 00 47 49 00 00 (PROP_SHUTTER_COUNTER)
[MPU] Sending : 08 07 01 55 00 02 01 01 (PROP_MULTIPLE_EXPOSURE_SETTING)
[MPU] Sending : 08 07 01 55 00 02 01 01 (PROP_MULTIPLE_EXPOSURE_SETTING)
[MPU] Sending : 08 07 01 55 00 02 01 01 (PROP_MULTIPLE_EXPOSURE_SETTING)
[MPU] Received: 08 06 00 00 01 55 00 00 (Complete WaitID = 0x8000003F PROP_MULTIPLE_EXPOSURE_SETTING - spell #3)
[MPU] Sending : 08 07 01 55 00 02 01 01 (PROP_MULTIPLE_EXPOSURE_SETTING)
[MPU] Received: 08 06 00 00 01 55 00 00 (Complete WaitID = 0x8000003F PROP_MULTIPLE_EXPOSURE_SETTING - spell #3)
[MPU] Received: 08 06 00 00 01 55 00 00 (Complete WaitID = 0x8000003F PROP_MULTIPLE_EXPOSURE_SETTING - spell #3)
[MPU] Received: 08 06 00 00 01 55 00 00 (Complete WaitID = 0x8000003F PROP_MULTIPLE_EXPOSURE_SETTING - spell #3)
[MPU] Received: 06 05 01 2e 01 00 (PROP_SAVE_MODE - spell #7)
[MPU] Sending : 06 05 01 2e 01 00 (PROP_SAVE_MODE)
[MPU] Received: 0a 08 03 0b 00 00 00 00 00 00 (PROP 80030007 - spell #8)
[MPU] Received: 08 07 03 54 00 03 00 00 (unknown - PROP_MPU_GPS)
[****] Starting task fe2be514(7969b4) ShootCapture
[****] Starting task fe2be514(7d88c4) ShootBlack
[****] Starting task fe0cd444(0) GuiLockTask
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #20)
[MPU] Sending : 0a 09 03 00 50 00 00 1b 01 00 (PROP 80030000)
[MPU] Sending : 06 05 03 04 00 00 (PROP_POWER_KIND)
[MPU] Sending : 1a 18 03 15 01 28 53 00 30 00 12 00 37 91 75 92 1f 00 ff ff ff ff ff ff 00 00 (PROP_LENS)
[MPU] Sending : 24 22 03 3c 00 00 17 3f bb 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (PROP 8003003C)
[MPU] Sending : 06 05 03 17 98 00 (PROP_EFIC_TEMP)
[MPU] Sending : 1a 18 03 15 01 28 53 00 30 00 12 00 37 91 75 92 1f 00 ff ff ff ff ff ff 00 00 (PROP_LENS)
[****] Starting task fe0c975c(0) MainCtrl
[MPU] Received: 06 05 01 56 00 00 (unnamed - spell #9)
[MPU] Received: 06 05 04 0e 01 00 (PROP 8002000D - spell #10)
[****] Starting task fe2be514(7d9118) TOMgr
[****] Starting task fe2be514(7da2c0) Fstorage
[****] Starting task fe2c2114(7db60c) AudioLevel
[****] Starting task fe2be514(7d8c74) ShootPreDevelop
[****] Starting task fe12b9c0(0) AEmodeJudge
[****] Starting task fe2c2114(671470) NFCMgr
[****] Starting task fe5423d8(0) CSMgrTask
[****] Starting task fe0c69c8(0) HotPlug
61: 202.496 [RSC] hMemoryQueue (0x660012) hStorageQueue (0x680014)
62: 208.128 [PRP] ERROR ILLEGAL PARAM SIZE ID = 0x80010004 L:794
63: 208.128 [PRP] PropertyList:12 Current:13
129: 290.048 [RTC] PROPAD_GetPropertyData : PROP_RTC 0xfd
130: 299.776 [RTC] ChangePropertyCBR 0x0, 0x0
131: 300.800 [RTC] RTC_Permit 0x20
142: 303.360 [SND] Seq LPC fin
159: 314.112 [ENG] [ENGIO](Addr:0x4fb40000, Data:0x 30000)
162: 357.120 [WB] AdjustWb Done.
176: 367.360 [TERMINATE] SHUTDOWN init comp
178: 367.872 [TERMINATE] Abort init comp
179: 368.384 [PRP] M:50 F:0 L:0 P:1B T:1
180: 369.152 [STARTUP] update inner version string. "4.4.6 50(1b)"
181: 369.408 [STARTUP] update coded version.
204: 387.584 [MC] PROP_GUI_STATE 0
209: 388.864 [MC] JobState 0
212: 391.936 [MC] PROP_LCD_OFFON_BUTTON : 0
214: 392.192 [MC] PROP_VARIANGLE_GUICTRL : Enable
217: 395.520 [MC] regist master CardCover
SD: Unknown CMD1
[SDIO] Error
SD: Unknown CMD1
[SDIO] Error
SD: Unknown CMD1
[SDIO] Error
244: 620.032 [SD] ERROR SDINTREP=0x00000000
245: 620.032 [SD] ERROR UNEXPECTED ERROR
[MPU] Received: 08 06 01 24 00 01 00 00 (PROP_CARD2_STATUS - spell #11)
[MPU] Sending : 08 06 01 24 00 01 00 00 (PROP_CARD2_STATUS)
[MPU] Received: 08 06 01 27 00 64 00 00 (PROP_CARD2_FOLDER_NUMBER - spell #12)
[MPU] Received: 08 07 01 2a 0a 6a 00 00 (PROP_CARD2_FILE_NUMBER - spell #13)
[MPU] Received: 06 05 03 07 15 00 (unknown - PROP_BURST_COUNT)
[MPU] Received: 0a 08 03 06 00 00 00 15 00 00 (unknown - PROP_AVAIL_SHOT)
[MPU] Received: 06 05 03 11 01 00 (PROP_ICU_AUTO_POWEROFF - spell #16)
[MPU] Received: 06 05 02 0a 00 00 (PROP_PERMIT_ICU_EVENT - spell #17)
[MPU] Sending : 06 05 01 2c 02 00 (PROP_CURRENT_MEDIA)
[****] Starting task fe2be514(8de0a4) FrontShtDevelop
[MPU] Received: 06 05 03 0d 00 00 (PROP_CARD2_RECORD - spell #18)
[MPU] Sending : 06 05 03 23 19 00 (unnamed)
[MPU] Received: 06 05 03 0c 00 00 (PROP_CARD1_RECORD - spell #19)
[MPU] Sending : 1e 1d 03 24 45 46 2d 53 31 38 2d 35 35 6d 6d 20 66 2f 33 2e 35 2d 35 2e 36 20 49 53 00 00 (PROP_LENS_NAME)
[****] Starting task fe2be514(8de534) RearShtDevelop
[MPU] Sending : 06 04 03 25 00 00 (unnamed)
[MPU] Sending : 06 05 01 3d 00 00 (PROP_TEMP_STATUS)
[MPU] Sending : 06 05 03 37 00 00 (PROP_MIRROR_DOWN_IN_MOVIE_MODE)
[MPU] Sending : 06 05 03 0d 00 00 (PROP_CARD2_RECORD)
[MPU] Sending : 06 05 03 0c 00 00 (PROP_CARD1_RECORD)
[DMA1] Copy [0xF8C60000] -> [0x408E2000], length [0x0000003C], flags [0x00030001]
[DMA1] OK
[****] Starting task fe2c2114(91a370) SoundEffect
[****] Starting task fe2c2114(91a80c) ASIF
[****] Starting task fe2c2114(91a95c) AudioCtrl
[MPU] Received: 06 05 04 1c 0c 00 (unknown - unnamed)
[MPU] Received: 06 05 04 1c 05 00 (unknown - unnamed)
[****] Starting task fe2c2114(930774) MovWriter
[****] Starting task fe2c2114(930bb8) MovieRecorder
[****] Starting task fe2c2114(931200) MoviePlay
[****] Starting task fe23cbc0(0) AviRead
[****] Starting task fe2c2114(931448) MovReader
[****] Starting task fe2c2114(9315a4) LVC_DEV
[****] Starting task fe0e1640(0) LVC_FACE
[****] Starting task fe2c2114(932238) Gmt
[MPU] Received: 06 05 09 11 01 00 (PROP_LV_DISPSIZE - spell #21)
[MPU] Received: 12 11 09 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (PROP 80050020 - spell #22)
[MPU] Received: 08 06 09 1f 00 00 00 00 (PROP 80050034 - spell #23)
[MPU] Received: 06 05 01 5a 00 00 (PROP_CONTINUOUS_AF_VALID - spell #24)
[MPU] Received: 06 05 01 5a 01 00 (PROP_CONTINUOUS_AF_VALID - spell #25)
[****] Starting task fe2c2114(936820) Evf
[****] Starting task fe2c2114(93f500) AeWb
[MPU] Received: 26 24 09 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (PROP_LV_FOCUS_DATA - spell #26)
[MPU] Received: 0a 08 09 1a 00 00 00 00 00 00 (PROP 8005002A - spell #27)
[****] Starting task fe2c2114(949170) LVFACE
[****] Starting task fe2c2114(94925c) LVC_MD
[****] Starting task fe2c2114(9494f8) MotionManager
[MPU] Received: 08 06 03 18 00 00 00 00 (PROP 8003000F - spell #28)
[MPU] Sending : 06 05 01 58 00 00 (PROP_VIDEOSNAP_MODE)
[MPU] Received: 08 06 03 1f 00 00 00 00 (PROP 80030019 - spell #29)
[MPU] Received: 08 06 04 20 00 00 00 00 (unknown - unnamed)
[MPU] Received: 06 05 03 13 00 00 (PROP_LOGICAL_CONNECT - spell #30)
[MPU] Received: 06 05 03 1e 00 00 (PROP 8003001A - spell #31)
[MPU] Received: 06 05 04 1f 00 00 (unknown - unnamed)
[MPU] Received: 08 07 03 55 00 00 00 00 (unknown - PROP 8003005A)
[MPU] Received: 06 05 03 56 00 00 (unknown - PROP 8003005B)
[MPU] Received: 08 07 01 3b ff ff 00 00 (unknown - PROP_USBDEVICE_CONNECT)
[MPU] Received: 08 07 01 3b ff 00 00 00 (unknown - PROP_USBDEVICE_CONNECT)
[****] Starting task fe108660(0) SoundDevice
[****] Starting task fe253b50(0) TestGero
[****] Starting task fe2c2114(93f42c) CLR_CALC
[****] Starting task fe2be514(9497ac) DaUSB20Drv
[****] Starting task fe1dba04(0) USBTrns
[****] Starting task fe1ebeec(0) SDIOTrns
[****] Starting task fe1da608(98a110) PTPSessionTASK
[****] Starting task fe2be514(98afd0) PtpDps
[****] Starting task fe2c2114(9e6c40) Ceres
[****] Starting task fe2be514(9edd70) Remote
[****] Starting task fe2be514(9f1460) Fcreate
[****] Starting task fe2c2114(9f2098) NwComMgr
[****] Starting task fe2be514(a47d3c) Fwrite
[****] Starting task fe2c2114(a48280) Sound
[MPU] Received: 08 07 01 2a 0a 6a 00 00 (PROP_CARD2_FILE_NUMBER - spell #32)
[****] Starting task fe2be514(a47af0) Fread
[****] Starting task fe2c2114(a4805c) Voice
[****] Starting task fe2c2114(a48398) WavReader
[****] Starting task fe2be514(a62284) ShootArtFilter
[****] Starting task fe2c2114(ad7b80) DisplayMgr
[****] Starting task fe0cc4bc(0) GuiMainTask
[****] Replacing task fe0cc4bc with c8edc0
[****] Starting task fe27e808(0) ImgPlayDrv
[EDMAC#18] Starting transfer to 0xD08700 from <6>, 3840x1079, flags=0x0
[EDMAC#18] Data unavailable; will try again later.
[EDMAC#13] Starting transfer from 0xD07800 to <6>, (3840, skip -3840) x 1079, flags=0x50000
[EDMAC#13] 4143360 bytes read from D07800-D08700.
[EDMAC#13] transfer delay 78 x 256 us.
[EDMAC#18] Starting transfer to 0xD08700 from <6>, 3840x1079, flags=0x0
[EDMAC#18] 4143360 bytes written to D08700-10FC000.
[EDMAC#18] transfer delay 77 x 256 us.
[HIV] Data unavailable; will try again later.
[****] Starting task fe299678(0) CtrlSrv
[****] Starting task fe2c2114(a5f0c4) ReDevelop
[****] Starting task fe2c2114(a5f168) DpMgr
[****] Starting task fe196770(0) DpsReceiveTask
[****] Starting task fe2c2114(a6136c) DpImgEditMgr
[****] Starting task fe2c2114(a615c4) InnerDevelopMgr
[****] Starting task fe2ab288(0) HDMIIP
[****] Starting task fe2374cc(0) EyeFi
[MPU] Received: 06 05 03 3d 00 00 (PROP_AFSHIFT_LVASSIST_STATUS - spell #33)
[EDMAC#18] Starting transfer to 0xC234700 from <6>, 3840x1079, flags=0x0
[EDMAC#18] Data unavailable; will try again later.
[EDMAC#13] Starting transfer from 0xC233800 to <6>, (3840, skip -3840) x 1079, flags=0x50000
[EDMAC#13] 4143360 bytes read from C233800-C234700.
[EDMAC#13] transfer delay 78 x 256 us.
[EDMAC#18] Starting transfer to 0xC234700 from <6>, 3840x1079, flags=0x0
[EDMAC#18] 4143360 bytes written to C234700-C628000.
[EDMAC#18] transfer delay 77 x 256 us.
[HIV] Data unavailable; will try again later.
[MPU] Received: 06 05 02 0a 01 00 (PROP_PERMIT_ICU_EVENT - spell #34)
[MPU] Sending : 06 05 06 11 01 00 (GUI_SWITCH)
[MPU] Sending : 06 05 06 12 00 00 (GUI_SWITCH)
[MPU] Sending : 06 05 06 13 00 00 (GUI_SWITCH)
[MPU] Sending : 06 05 06 1c 00 00 (GUI_SWITCH)
[MPU] Sending : 06 05 06 26 01 00 (GUI_SWITCH)
[MPU] Sending : 44 43 0a 08 ff 1f 01 00 01 03 98 0c 00 45 01 01 53 28 53 01 01 00 00 04 01 00 23 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (PD_NotifyOlcInfoChanged)
[MPU] Sending : 06 05 04 0e 01 00 (PROP 8002000D)
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #37)
[BOOT] my_init_task completed.
======================================
= jump vector allocation =
======================================
jump-vector using malloc == 0xeeef0 (978672)
jump-vector alloca == 0x14b5f8 (1357304)
jump_vector_static == 0xcf6400 (13591552)
jump vector winner was _malloc
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #38)
[MPU] Received: 06 05 03 19 01 00 (PROP_TFT_STATUS - spell #75)
[MPU] Received: 06 05 08 06 ff 00 (COM_FA_CHECK_FROM - spell #40)
[MPU] Sending : 06 05 08 06 00 00 (COM_FA_CHECK_FROM)
jump vector allocation done[****] Starting task fe32cba0(0) PTPtoFAPI_EventProcTask
[****] Starting task fe2c2114(a5ec24) Mrk
[****] Starting task fe2c2114(9f7a4c) MetaCtg
[MPU] Received: 06 05 03 19 00 00 (PROP_TFT_STATUS - spell #41)
[****] Starting task fe149508(0) LpfMode
[****] Starting task c81300(0) ml_init
405: 879.104 [LV] [GMTLens moving (0, 0)
jump_vector - from boot.h = eeef0
jump_vector - aligned = eeef0
] PROP_TEMP_STATUS : STATUS_NORMAL
527: 913.664 [LV] InitializeLiveViewDefectDetection
541: 948.480 [MD] Init RCh1=0, RCh2=0
544: 950.784 [MD] Set RCh1=d, RCh2=18
867: 1175.808 [INDEV] INDEV_Initialize
874: 1186.816 [HDMI] [MID] HDMI_IP_Initialize
887: 1257.728 [IMPP] H264E InitializeH264EncodeFor1080pDZoom
888: 1257.984 [IMPP] H264E InitializeH264EncodeFor1080p25fpsDZoom
924: 1320.448 [MR_MOV] (Empty Func) MVW_RegisterXmpDataCallback
966: 1361.920 WARN [LVDS] First Get DTS_GetAllRandomData
1064: 1415.168 [GUI] MainEventHandler PROP_QR_DIDNOT_EXECUTE(0)(0)
1111: 1436.672 [STARTUP] startupInitializeComplete
1113: 1437.696 [MC] cam event guimode comp. 0
1238: 1540.608 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown MovieInfo
1239: 1540.864 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
1257: 1545.728 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown MovieInfo
1258: 1545.728 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
1261: 1546.752 [MC] cam event guimode comp. 0
1305: 1857.024 [DISP] TurnOnDisplay action Type=0
[****] Starting task c88c7c(0) menu_task
[****] Starting task c8b954(0) menu_redraw_task
[****] Starting task c94930(0) bitrate_task
[****] Starting task ca0324(0) focus_task
[****] Starting task ca0e78(0) notifybox_task
[****] Starting task ca368c(0) fps_task
[****] Starting task ca7288(0) shoot_task
[****] Starting task ca50e4(0) clock_task
[****] Starting task cad85c(0) audio_common_task
[****] Starting task cb4d8c(0) livev_hiprio_task
[****] Starting task cb35e4(0) cls_task
[****] Starting task cb67a8(0) beep_task
[****] Starting task cc07ec(0) console_task
[****] Starting task c8de90(0) debug_task
[****] Starting task c96154(0) tweak_task
[****] Starting task ca0b50(0) focus_misc_task
[****] Starting task ca8bec(0) vignetting_init
[****] Starting task cc6030(0) module_task
[****] Starting task c80c38(0) ml_backup
[****] Starting task cb4444(0) livev_loprio_task
============================================
======== Camera modole 1300D
======== Memory before patching =======
============================================
failure_stubs1 addr c80abc (e92d4008)
failure_stubs2 addr c80aa0 (e92d4008)
failure_stubs3 addr c80a84 (e92d4008)
failure_stubs4 addr c80a6c (e92d4008)
failure_stubs5 addr c80a50 (e92d4008)
failure_stubs6 addr c80a34 (e92d4008)
failure_stubs7 addr c80a18 (e92d4008)
success_stubs addr c80a00 (e92d4008)
============================================
= Testing cache_fake (QEMU ROM patching) =
============================================
* calling failure_stub1, return value expected (1001) actual = 1001
* calling success_stub , return value expected (1) actual = 1
* patching using old patching method, (jump only few bytes) rerouting to succes_stubs (0)
* calling failure_stub1, return value expected (1) actual = 1
* Test was a success
============================================
= Testing MEM(data) (QEMU ROM patching) =
============================================
* calling failure_stub2, return value expected (1002) actual = 1002
* calling success_stub , return value expected (1) actual = 1
* patching done
* calling failure_stub2, return value expected (1) actual = 1
* Test was a success
============================================
= Simple double jump (relative) hardcoded =
============================================
* calling failure_stub3, return value expected (1003) actual = 1003
* calling success_stub , return value expected (1) actual = 1
* patching done
* calling failure_stub3, return value expected (1) actual = 1
* Test was a success
============================================
= Simple double jump: =
= patch_instruction + MEM(data) patch =
============================================
* calling failure_stub4, return value expected (1004) actual = 1004
* calling success_stub , return value expected (1) actual = 1
* patching done
* calling failure_stub4, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (double rel jump) =
============================================
* calling failure_stub5, return value expected (1005) actual = 1005
* calling success_stub , return value expected (1) actual = 1
* using jump_vector 0 (address eeef0)
* double relative
* patching done
* calling failure_stub5, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (single rel jump) =
============================================
* calling failure_stub6, return value expected (1006) actual = 1006
* calling success_stub , return value expected (1) actual = 1
* patch_instruction = Using single jump
* patching done
* calling failure_stub6, return value expected (1) actual = 1
* Test was a success
============================================
= patch_instruction_jump (rel+abs jump) =
= This is primary goal :) =
============================================
* calling failure_stub7, return value expected (1007) actual = 1007
* calling success_stub , return value expected (1) actual = 1
* using jump_vector 1 (address eeefc)
* relative plus absolute (trampoline)
* patching done
* calling failure_stub7, return value expected (1) actual = 1
* Test was a success
============================================
======== Memory after patching =======
============================================
failure_stubs1 addr c80abc (eaffffcf)
failure_stubs2 addr c80aa0 (eaffffd6)
failure_stubs3 addr c80a84 (ea01a567)
failure_stubs4 addr c80a6c (ea01a56d)
failure_stubs5 addr c80a50 (ead1b926)
failure_stubs6 addr c80a34 (eafffff1)
failure_stubs7 addr c80a18 (ead1b937)
success_stubs addr c80a00 (e92d4008)
============================================
============ Done ==========================
============================================
updating Movie Tweaks -> Movie Logging
updating Movie Tweaks -> Time Indicator
[NotifyBox] Camera was not shut down cleanly.
Skipping module loading.
The tests were so far a success. I tryed to allocate 3 different way to see which allocate has the lowest address (there are more
ways to allocate but I have not included them yet !). This address will be used a jump table, and the winner is canon's malloc:
======================================
= jump vector allocation =
======================================
jump-vector using malloc == 0xeeef0 (978672)
jump-vector alloca == 0x14b5f8 (1357304)
jump_vector_static == 0xcf6400 (13591552)
jump vector winner was _malloc
The rom starts at 0xFE0C0000, but our allocation start at 0xeeef0, that is a jump over 32MB so there we can't hijack the very start, but it's
really close and we can use that to continue working on the 1300d for now. With this alternative patch function we can hijack
from 0xFE0EEEF0 to 0xFFFFFFFF which is more or less everything (~99.99%).
Todo
1. Use other allocation routines to find the lowest address (would be nice if we could get allocation address below 0xC0000)
2. Implement a unpatch function
3. Cleanup and make the code pretty.
My updated 1300D cooking recipe
(my gcc = arm-none-eabi-gcc-4.7.4)
1. Download 1300d branch (https://bitbucket.org/hudson/magic-lantern/branch/1300D)
2. Overwrite some files from https://github.com/jmheder/ml/raw/master/update1.zip (patch.c,patch.hinit.c,boot-hack.h,boot-45d-ch.c,fw_signatures.h)
3. Compile QEMU from QEMU branch (https://bitbucket.org/hudson/magic-lantern/branch/QEMU)
4. Update 1300D ROM1.bin
dd if=ROM1.BIN of=BOOT.BIN bs=64K skip=1 count=1
dd if=BOOT.BIN of=ROM1.BIN bs=64K seek=511
5. Update 1300D ROM0.bin (ROM0.bin = garbage, better use empty ROM0.bin)
mv ROM0.bin ROM0.bin.orig
touch ROM0.bin
6. Execute "make autoexec.bin" inside the 1300D platrform.
7. Run autoexec.bin in QEMU
How to use this temporary patch instruction jump function:
If you are hijacking a complete function (this is normally what we do ...):
patch_instruction_jump((uintptr_t)function_to_hijack,(uint32_t)function_to_hijack,(uint32_t)new_function,JUMP_B," hijacking some function ",2);
If you are hijacking a single instruction or branch instruction (BL) and turning it into a new BL:
patch_instruction_jump((uintptr_t)address_to_hijack,(uint32_t)address_to_hijack,(uint32_t)new_function,JUMP_BL," jumping from within some function",2);
Thank you, @heder.
A1ex, can you check what @heder did? If you think it's ok, can ML be run on the 1300D?
Thank you.
I night be wrong, but i dont see why we need my alternative patch function to run ML in 1300D. The only reason we need it is to develop ML for 1300D. Once ML is completed my patch function becomes useless. Its only a development tool.
I didn't ask the right question. I wanted to ask a1ex if the bootflag can now be set to 1300D.
Thanks
Quote from: critix on July 25, 2020, 07:49:31 PM
I didn't ask the right question. I wanted to ask a1ex if the bootflag can now be set to 1300D.
Thanks
Ok, thats a1ex's job.
But a1ex (https://www.magiclantern.fm/forum/index.php?action=profile;area=showposts;u=3) hasn't posted on the forum for 4 weeks...
Busy with repository migration, maybe? Last active 24th of July, though. No worries!
I have finalized the new function. I have updated the development patch_instruction_jump for 1300D. patch_instruction_jump will only be enabled on 1300D builds, as others do not need that one right now. Since bitbucket is read-only the patch are not checked, the only solution is a zip file with modified files.
1. Download 1300d branch (https://bitbucket.org/hudson/magic-lantern/branch/1300D)
2. Overwrite files in patch-update.zip from https://github.com/jmheder/ml/raw/master/patch_update.zip
3. Compile QEMU from QEMU branch (https://bitbucket.org/hudson/magic-lantern/branch/QEMU)
4. Update 1300D ROM1.bin
dd if=ROM1.BIN of=BOOT.BIN bs=64K skip=1 count=1
dd if=BOOT.BIN of=ROM1.BIN bs=64K seek=511
5. Update 1300D ROM0.bin (ROM0.bin = garbage, better use empty ROM0.bin)
mv ROM0.bin ROM0.bin.orig
touch ROM0.bin
6. Execute "make autoexec.bin" inside the 1300D platrform.
7. Run autoexec.bin in QEMU
I performed a verification on DryosDebugMsg, similar the a1ex'es here (https://www.magiclantern.fm/forum/index.php?topic=17969.msg211084#msg211084). I hijacked DryosDebugMsg and intercepted ~750 messages, before
I then unpatched it again, and let the system run for a while, and last I called dumpf log. Everything worked as excepted.
So final instruction are:
patch_instruction_jump(uintptr_t rom_func_addr, uintptr_t new_func_addr, uint32_t jump_type, const char * description);
rom_func_addr = address in rom of function
new_func_addr = address of new function
jump_type = JUMP_B for normal hijack (~ overwrite function), JUMP_BL if you are replacing an existing bl instruction
description = ...
unpatch_memory(uintptr_t rom_func_addr)
rom_func_addr = undo patch at address
Is there any update on the progress?
Does this mean we can use ML on 1300D?
No. It means progress is still being made.
There is no percentage to know how it goes? :'(
ML project has no timeline, milestones to reach, release dates to match. None.
It's done by highly skilled people in their spare time stolen from family, friends and other hobbies.
Ok, I did some tests with selftest and benchmark modules. The results are as follows:
(https://i.postimg.cc/zV5CnG8H/buffer-benchmark.jpg) (https://postimg.cc/zV5CnG8H)
(https://i.postimg.cc/XpZsrhvr/card-benchmark.jpg) (https://postimg.cc/XpZsrhvr)
(https://i.postimg.cc/jDSyF3Ws/memory-benchmark.jpg) (https://postimg.cc/jDSyF3Ws)
(https://i.postimg.cc/8j0b01zz/memory-leak-test.jpg) (https://postimg.cc/8j0b01zz)
The stubtest log is:
[Pass] is_play_mode() => 0x1
[INFO] Camera model: Canon EOS 1300D 1.1.0 (0x80000404 1300D)
[Pass] is_camera("DIGIC", "*") => 0x1
[Pass] is_camera(__camera_model_short, firmware_version) => 0x1
[Pass] src = fio_malloc(size) => 0x423880f0
[Pass] dst = fio_malloc(size) => 0x42b8c0fc
[Pass] memcmp(dst, src, 4097) => 0xffffff26
[Pass] edmac_memcpy(dst, src, 4097) => 0x42b8c0fc
[Pass] memcmp(dst, src, 4097) => 0x0
[Pass] edmac_memcpy(dst, src, 4097) => 0x42b8c0fc
[Pass] memcmp(dst, src, size) => 0xffffff12
[Pass] edmac_memcpy(dst, src, size) => 0x42b8c0fc
[Pass] memcmp(dst, src, size) => 0x0
[Pass] memcmp(dst, src, size) => 0xd6
[Pass] edmac_memcpy_start(dst, src, size) => 0x42b8c0fc
dt => 0x0
[Pass] copied => 0x800000
[Pass] copied => 0x800000
[Pass] copied => 0x800000
[Pass] memcmp(dst, src, copied) => 0x0
[FAIL] memcmp(dst, src, copied + 16) => 0x0
edmac_memcpy_finish()
free(src)
free(dst)
Cache test A (EDMAC on BMP buffer)...
[Pass] bmp = bmp_load("ML/CROPMKS/CINESCO2.BMP", 1) => 0xa1056c
[Pass] old => 0x0
[Pass] irq => 0xc0
[FAIL] differences => 0x0
[Pass] old => 0x0
[Pass] irq => 0xc0
[Pass] differences => 0x0
Cache test B (FIO on 8K buffer)...
[Pass] tries[0] => 0xf4
[Pass] tries[1] => 0x103
[Pass] tries[2] => 0x10e
[Pass] tries[3] => 0xe3
[FAIL] failr[0] => 0x0
[FAIL] failw[0] => 0x0
[FAIL] failr[1] => 0x0
[Pass] failw[1] => 0x0
[Pass] failr[2] => 0x0
[FAIL] failw[2] => 0x0
[Pass] failr[3] => 0x0
[Pass] failw[3] => 0x0
times[0] / tries[0] => 0x4
times[1] / tries[1] => 0x4
times[2] / tries[2] => 0x4
times[3] / tries[3] => 0x4
Cache tests finished.
[Pass] f = FIO_CreateFile("test.dat") => 0x3
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
[Pass] FIO_WriteFile(f, (void*)0xFF000000, 0x10000) => 0x10000
FIO_CloseFile(f)
[Pass] FIO_GetFileSize("test.dat", &size) => 0x0
[Pass] size => 0x20000
[Pass] p = (void*)_alloc_dma_memory(0x20000) => 0x40c18700
[Pass] f = FIO_OpenFile("test.dat", O_RDONLY | O_SYNC) => 0x3
[Pass] FIO_ReadFile(f, p, 0x20000) => 0x20000
FIO_CloseFile(f)
_free_dma_memory(p)
[Pass] count => 0x3a98
[Pass] buf = fio_malloc(0x1000000) => 0x423880f0
[FAIL] FIO_GetFileSize_direct("test.dat") => 0xcc34000
[Pass] f = FIO_OpenFile("test.dat", O_RDWR | O_SYNC) => 0x3
[FAIL] FIO_SeekSkipFile(f, 0, SEEK_END) => 0xcc34000
[FAIL] FIO_WriteFile(f, buf, 0x10) => 0xffffffff
[FAIL] FIO_SeekSkipFile(f, -0x20, SEEK_END) => 0xcc33fe0
[FAIL] FIO_WriteFile(f, buf, 0x30) => 0xffffffff
[Pass] FIO_SeekSkipFile(f, 0x20, SEEK_SET) => 0x20
[Pass] FIO_SeekSkipFile(f, 0x30, SEEK_CUR) => 0x50
[Pass] FIO_SeekSkipFile(f, -0x20, SEEK_CUR) => 0x30
[FAIL] FIO_GetFileSize_direct("test.dat") => 0xcc34000
[Pass] is_file("test.dat") => 0x1
[Pass] FIO_RemoveFile("test.dat") => 0x0
[Pass] is_file("test.dat") => 0x0
[Pass] SetTimerAfter(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x5b74
msleep(900)
[Pass] timer_func => 0x0
msleep(200)
[Pass] timer_func => 0x1
[FAIL] ABS((timer_time/1000 - t0) - 1000) => 0x15
[Pass] ABS((timer_arg - ta0) - 1000) => 0xa
[Pass] timer = SetTimerAfter(1000, timer_cbr, overrun_cbr, 0) => 0x5b9c
msleep(400)
CancelTimer(timer)
[Pass] timer_func => 0x0
msleep(1500)
[Pass] timer_func => 0x0
[Pass] SetHPTimerAfterNow(0, timer_cbr, overrun_cbr, 0) => 0x15
[Pass] timer_func => 0x2
[Pass] SetHPTimerAfterNow(100000, timer_cbr, overrun_cbr, 0) => 0x3fc
msleep(90)
[Pass] timer_func => 0x0
msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 100000) => 0x260
[Pass] ABS(DeltaT(timer_arg, ta0) - 100000) => 0x200
[Pass] ABS((get_us_clock() - t0) - 110000) => 0xfffff850
[Pass] SetHPTimerAfterNow(90000, next_tick_cbr, overrun_cbr, 0) => 0x3fe
msleep(80)
[Pass] timer_func => 0x0
msleep(20)
[Pass] timer_func => 0x3
msleep(80)
[Pass] timer_func => 0x3
msleep(20)
[Pass] timer_func => 0x1
[Pass] ABS(DeltaT(timer_time, t0) - 300000) => 0x5e0
[Pass] ABS(DeltaT(timer_arg, ta0) - 300000) => 0x6b0
[Pass] ABS((get_us_clock() - t0) - 310000) => 0xffffe210
t0 = GET_DIGIC_TIMER() => 0x35600
msleep(250)
t1 = GET_DIGIC_TIMER() => 0x6f900
[Pass] ABS(MOD(t1-t0, 1048576)/1000 - 250) => 0xc
LoadCalendarFromRTC( &now )
s0 = now.tm_sec => 0x0
Date/time: 2017/09/30 15:15:00
msleep(1500)
LoadCalendarFromRTC( &now )
s1 = now.tm_sec => 0x0
[FAIL] MOD(s1-s0, 60) => 0x0
[Pass] MOD(s1-s0, 60) => 0x0
m0 = MALLOC_FREE_MEMORY => 0x40370
[Pass] p = (void*)_malloc(50*1024) => 0x1017a0
[Pass] CACHEABLE(p) => 0x1017a0
m1 = MALLOC_FREE_MEMORY => 0x33b60
_free(p)
m2 = MALLOC_FREE_MEMORY => 0x40370
[Pass] ABS((m0-m1) - 50*1024) => 0x10
[Pass] ABS(m0-m2) => 0x0
m0 = GetFreeMemForAllocateMemory() => 0x9cb74
[Pass] p = (void*)_AllocateMemory(128*1024) => 0xc186f0
[Pass] CACHEABLE(p) => 0xc186f0
m1 = GetFreeMemForAllocateMemory() => 0x7cb68
_FreeMemory(p)
m2 = GetFreeMemForAllocateMemory() => 0x9cb74
[Pass] ABS((m0-m1) - 128*1024) => 0xc
[Pass] ABS(m0-m2) => 0x0
m01 = MALLOC_FREE_MEMORY => 0x40370
m02 = GetFreeMemForAllocateMemory() => 0x9cb74
[Pass] p = (void*)_alloc_dma_memory(128*1024) => 0x40c18700
[Pass] UNCACHEABLE(p) => 0x40c18700
[Pass] CACHEABLE(p) => 0xc18700
[Pass] UNCACHEABLE(CACHEABLE(p)) => 0x40c18700
_free_dma_memory(p)
[Pass] p = (void*)_shoot_malloc(16*1024*1024) => 0x423880e0
[Pass] UNCACHEABLE(p) => 0x423880e0
_shoot_free(p)
m11 = MALLOC_FREE_MEMORY => 0x40370
m12 = GetFreeMemForAllocateMemory() => 0x9cb74
[Pass] ABS(m01-m11) => 0x0
[Pass] ABS(m02-m12) => 0x0
[Pass] suite = shoot_malloc_suite_contig(16*1024*1024) => 0x1017a0
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1000000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1017c8
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1000000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x423880dc
[Pass] UNCACHEABLE(p) => 0x423880dc
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite_contig(0) => 0x1017a0
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x1
[Pass] suite->size => 0x1f68000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1017c8
[Pass] chunk->signature => 'MemChunk'
[Pass] chunk->size => 0x1f68000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4a000064
[Pass] UNCACHEABLE(p) => 0x4a000064
largest_shoot_block = suite->size => 0x1f68000
[INFO] largest_shoot_block: 31MB
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(largest_shoot_block + 1024*1024) => 0x1017a0
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x3
[Pass] suite->size => 0x2068000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1017c8
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1c74000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x423880dc
[Pass] UNCACHEABLE(p) => 0x423880dc
chunk = GetNextMemoryChunk(suite, chunk) => 0x101828
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1d9c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42100064
[Pass] UNCACHEABLE(p) => 0x42100064
chunk = GetNextMemoryChunk(suite, chunk) => 0x101860
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x2068000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x41878064
[Pass] UNCACHEABLE(p) => 0x41878064
chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x2068000
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] suite = shoot_malloc_suite(0) => 0x1017a0
[Pass] suite->signature => 'MemSuite'
[Pass] suite->num_chunks => 0x4
[Pass] suite->size => 0x4300000
[Pass] chunk = GetFirstChunkFromSuite(suite) => 0x1017c8
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1c74000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x423880dc
[Pass] UNCACHEABLE(p) => 0x423880dc
chunk = GetNextMemoryChunk(suite, chunk) => 0x101828
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x1d9c000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x42100064
[Pass] UNCACHEABLE(p) => 0x42100064
chunk = GetNextMemoryChunk(suite, chunk) => 0x101860
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x3d04000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x4a000064
[Pass] UNCACHEABLE(p) => 0x4a000064
chunk = GetNextMemoryChunk(suite, chunk) => 0x101898
[Pass] chunk->signature => 'MemChunk'
[Pass] total += chunk->size => 0x4300000
[Pass] p = GetMemoryAddressOfMemoryChunk(chunk) => 0x41878064
[Pass] UNCACHEABLE(p) => 0x41878064
chunk = GetNextMemoryChunk(suite, chunk) => 0x0
[Pass] total => 0x4300000
shoot_free_suite(suite); suite = 0; chunk = 0;
[Pass] strlen("abc") => 0x3
[Pass] strlen("qwertyuiop") => 0xa
[Pass] strlen("") => 0x0
[Pass] strcpy(msg, "hi there") => 0x1ad7e4
[Pass] msg => 'hi there'
[Pass] snprintf(a, sizeof(a), "foo") => 0x3
[Pass] snprintf(b, sizeof(b), "foo") => 0x3
[Pass] strcmp(a, b) => 0x0
[Pass] snprintf(a, sizeof(a), "bar") => 0x3
[Pass] snprintf(b, sizeof(b), "baz") => 0x3
[Pass] strcmp(a, b) => 0xfffffff8
[Pass] snprintf(a, sizeof(a), "Display") => 0x7
[Pass] snprintf(b, sizeof(b), "Defishing") => 0x9
[Pass] strcmp(a, b) => 0x4
[FAIL] snprintf(buf, 3, "%d", 1234) => 0x4
[Pass] buf => '12'
[Pass] memcpy(foo, bar, 6) => 0x1ad880
[Pass] foo => 'asdfghuiop'
[Pass] memset(bar, '*', 5) => 0x1ad860
[Pass] bar => '*****hjkl;'
bzero32(bar + 5, 5)
[FAIL] bar => '*****'
EngDrvOut(LCD_Palette[0], 0x1234)
[Pass] shamem_read(LCD_Palette[0]) => 0x1234
call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
call("TurnOffDisplay")
[Pass] DISPLAY_IS_ON => 0x0
call("TurnOnDisplay")
[Pass] DISPLAY_IS_ON => 0x1
task_create("test", 0x1c, 0x1000, test_task, 0) => 0x15ea00c8
[Pass] test_task_created => 0x1
[Pass] get_current_task_name() => 'run_test'
[FAIL] get_task_name_from_id(current_task->taskId) => '?'
[Pass] task_max => 0x88
[Pass] task_max => 0x88
[Pass] mq = mq ? mq : (void*)msg_queue_create("test", 5) => 0x15ec009c
[Pass] msg_queue_post(mq, 0x1234567) => 0x0
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x0
[Pass] m => 0x1234567
[Pass] msg_queue_receive(mq, (struct event **) &m, 500) => 0x9
[Pass] sem = sem ? sem : create_named_semaphore("test", 1) => 0x15ee01c2
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] take_semaphore(sem, 500) => 0x9
[Pass] give_semaphore(sem) => 0x0
[Pass] take_semaphore(sem, 500) => 0x0
[Pass] give_semaphore(sem) => 0x0
[Pass] rlock = rlock ? rlock : CreateRecursiveLock(0) => 0x15f000d8
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] AcquireRecursiveLock(rlock, 500) => 0x0
[Pass] ReleaseRecursiveLock(rlock) => 0x0
[FAIL] ReleaseRecursiveLock(rlock) => 0x0
SetGUIRequestMode(1); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x1
SetGUIRequestMode(2); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x2
SetGUIRequestMode(0); msleep(1000);
[Pass] CURRENT_GUI_MODE => 0x0
[FAIL] display_idle() => 0x0
GUI_Control(BGMT_PLAY, 0, 0, 0); msleep(1000);
[Pass] PLAY_MODE => 0x1
[Pass] MENU_MODE => 0x0
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(1000);
[Pass] MENU_MODE => 0x1
[Pass] PLAY_MODE => 0x0
[Pass] dialog->type => 'DIALOG'
GUI_Control(BGMT_MENU, 0, 0, 0); msleep(500);
[Pass] MENU_MODE => 0x0
[Pass] PLAY_MODE => 0x0
SW1(1,100)
[FAIL] HALFSHUTTER_PRESSED => 0x0
SW1(0,100)
[Pass] HALFSHUTTER_PRESSED => 0x0
[Pass] is_play_mode() => 0x1
[FAIL] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[FAIL] is_pure_play_movie_mode() => 0x0
[Pass] is_play_mode() => 0x1
[Pass] is_pure_play_photo_mode() => 0x0
[Pass] is_pure_play_movie_mode() => 0x0
=========================================================
Test complete, 11499 passed, 22 failed.
.
I saw such numbers in card benchmarks if card is full.
Yes you are right...
OK, I did the card tests again, but this time I set sd.img default.
The results are:
(https://i.postimg.cc/ZCWvpccW/card-benchmark-2.jpg) (https://postimg.cc/ZCWvpccW)
Hey guys,
I'm a reasonably competent (albeit high-level) programmer, and I'd be happy to help out once I can wrap my head around some of the lower level hardware stuff. I know enough C to get by, but definitely need to read up on some ARM stuff.
I also have a 1300D so if you need rom dumps or hardware tests (eventually) then I'd be happy to.
Anyway if there's any resources you guys can point me to I'd be happy to go have a read :)
-Mitch.
Sticky tweet in twitter.com/autoexec_bin
Unofficial ML Discord Server: https://discord.gg/uaY8akC
Get QEMU running, start diving in. Use Discord for online support (if necessary).
As an owner of a 1300D/T6 I am definitely excited at the possibility of using ML in the future. I know there are plenty of these type posts here, but I really am curious to know if there is anything I can do to help with this port. I am a software engineer, but I'm mostly unfamiliar with this type of low level embedded work. Does the ML team (or anyone working on the 1300D/T6 port) accept donations? I would like to contribute to this effort in any way I can.
See posting above
ATM donations won't help but this may change soon.
I was looking into helping out with the code.
Is this the most recent branch?
https://foss.heptapod.net/magic-lantern/magic-lantern/-/tree/topic/1300D/bitbucket-pr-951/
Quote from: Walter Schulz on October 11, 2020, 11:12:00 AM
See posting above
ATM donations won't help but this may change soon.
Thanks for the info.
I'm not sure this helps, but there also seems to be a deticated "1300D" branch https://foss.heptapod.net/magic-lantern/magic-lantern/-/tree/branch/1300D (https://foss.heptapod.net/magic-lantern/magic-lantern/-/tree/branch/1300D)
There is also another branch,
https://foss.heptapod.net/magic-lantern/magic-lantern/-/tree/topic/1300D/bitbucket-pr-951
It got its last commit 1 year ago whereas
https://foss.heptapod.net/magic-lantern/magic-lantern/-/tree/branch/1300D
seems to be last committed 2 years ago.
I ran a ROM dump on my 1300D and have been playing with it in QEMU. Seems to work flawlessly despite
a bunch of errors being spit into the console.
I compiled some of heder's changes, but can't figure out how to run the autoexec.bin in QEMU.
Hi petabyte
The command to execute ML booting on 1300D in QEMU is
./run_canon_fw.sh 1300D,firmware="boot=1"
1. Remeber to copy your ROM files into the 1300D directory
2. Follow my instruction from https://www.magiclantern.fm/forum/index.php?topic=17969.msg229296#msg229296 (rom updating)
The console should at some point write :
SD LOAD OK.
Open file for read : AUTOEXEC.BIN
File size : 0x6FBA0
Now jump to AUTOEXEC.BIN!!
After booting, press delete bottom for entering ML menu.
Thanks, `./run_canon_fw.sh 1300D,firmware="boot=1"` is what I needed. It boots, but I have the wrong firmware on my camera. 1.1.1 instead of 1.1.0.
Use Wayback Machine to look after archived versions of pel.hu/down/v110-t6-1300d-x80-win.exe
Surprise! Still online https://id.canon/en/support/0400290302/1
I did try that. It won't let me upgrade. "Firmware older than Ver. 1.1.1 is on memory card. Delete old file and update using later version."
Maybe it will work on EOS Utility? I will boot into Windows and try that.
Also, 1.1.1 fixed a "vulnerability when updating firmware"
Quote from: petabyte on January 21, 2021, 04:54:07 PM
I did try that. It won't let me upgrade. "Firmware older than Ver. 1.1.1 is on memory card. Delete old file and update using later version."
Look after instructions in https://builds.magiclantern.fm/5D3-113.html for 5D3 with firmware 1.3.3 - 1.3.5
Try EOS Utility first. If it fails: Method B!
Don't be afraid, it works! There is an instruction video https://www.magiclantern.fm/forum/index.php?topic=24926.msg231788#msg231788
You have to be fast or you have to restart.
Thanks, method B worked first time. Trying to load the firmware returns "Memory card containing firmware is required to update." though.
Log: https://petabyte.heb12.com/filedump/1300d%20log
Hi petabyte
just to be 100%
1. You downgraded your 1300D camera to 1.1.0 (with success)
2. You dump'ed the rom (1.1.0) to sd-card
3. You change the rom (1.1.0) using my instructions
4. You ran QEMU and got "Memory card containing firmware is required to update."
Yes. It says it is 1.1.0 in the log file.
That is when I run the firmware from the update option in the Canon ROM
I repulled and recompiled, still "Memory card containing firmware is required to update." when trying to load 1.1.0-ml-nightly. Is this as expected?
The minimal hello world seems to run though.
Quote from: petabyte on January 21, 2021, 08:09:42 PM
I repulled and recompiled, still "Memory card containing firmware is required to update." when trying to load 1.1.0-ml-nightly. Is this as expected?
The minimal hello world seems to run though.
Hi petabyte
A couple of ideas to track down your isssue, but I suspect that the issue itself is your compilation or compiler.
1. In Makefile.user set CONFIG_QEMU = y (this will keep the build more stable on QEMU)
2. What version of GCC are you using ? Personally I only old onces : gcc-4.7.4 or gcc 5.4.1. These can be found on https://launchpad.net/
3. Be aware that in some rare cases the sd.img can be conterminated, but since your hello world is working this is not the issue.
I've been using arm gcc 5.4.1. I set CONFIG_QEMU, but nothing changed.
Recording just to be sure: http://petabyte.heb12.com/filedump/ml_foo.mp4
Also I was a bit confused on the building process. Do I run `make install_qemu`?
You previously said "make autoexec.bin" and then run it in QEMU.
Edit: I think I got it working right. I got the ML UI working.
Hi petabyte
Briliant idea to make a video :), a image says more than a 1000 words.
Your console says your trying to enter ML via space key , your console = "Key event: 39 -> 0xc01"
But you should be using delete key, my console = "Key event: 59 -> 0401"
(But If you are infact using delete and QEMU translated this into key event for space, then the problem is qemu and then you should recompile and use SDL)
I had figured that out, but thanks. I had to press A.
Some updates:
The 1300D has UART port accessible by removing the thumb grip above the DPAD. Some 1300D do not have the connector soldered on, but the pads on the PCB are visible. I was able to probe test the pins and got a pinout diagram:
Pin No. | | | 1 | | | 2 | | | 3 | | | 4 | | | 5 | | | 6 | | |
STATE | | | 0V | | | 3V3 | | | 3V3 | | | G | | | 3V3 | | | 3V3 | | |
Func. | | | MPU Rx | | | MPU Tx | | | UNKNOWN | | | GND | | | CPU Rx | | | CPU Tx | | |
Console outputsProbing pin 2 gives:
(https://cdn.discordapp.com/attachments/789206911886950411/805669600250691614/unknown.png)
Probing Pin 6 gives:
#
2010: 14066.703 [FM] FM_Suspend : Normal
Firm Jump RAM to ROM 0xFE0C0000
K404 READY
0: 13.602 [STARTUP]
K404 ICU Firmware Version 1.1.0 ( 4.4.6 )
57: 119.351 [RSC] hMemoryQueue (0x660012) hStorageQueue (0x680014)
121: 137.499 [RTC] PROPAD_GetPropertyData : PROP_RTC 0xfd
122: 138.857 [RTC] ChangePropertyCBR 0x0, 0x4000
123: 139.113 [RTC] RTC_Permit 0x20
134: 139.440 [SND] Seq LPC fin
151: 142.332 [ENG] [ENGIO](Addr:0x4fb40000, Data:0x 30000)
154: 150.577 [WB] AdjustWb Done.
168: 152.797 [TERMINATE] SHUTDOWN init comp
170: 152.884 [TERMINATE] Abort init comp
192: 156.561 [MC] PROP_GUI_STATE 0
197: 156.859 [MC] JobState 0
200: 157.573 [MC] PROP_LCD_OFFON_BUTTON : 1
202: 157.758 [MC] PROP_VARIANGLE_GUICTRL : Enable
205: 158.770 [MC] regist master CardCover
248: 174.656 [PRP] M:37 F:0 L:0 P:B T:1
378: 254.481 [LV] [GMT] PROP_TEMP_STATUS : STATUS_NORMAL
498: 264.995 [LV] InitializeLiveViewDefectDetection
902: 299.478 [MD] Init RCh1=0, RCh2=0
905: 300.002 [MD] Set RCh1=d, RCh2=18
1292: 863.742 [INDEV] INDEV_Initialize
1299: 865.931 [HDMI] [MID] HDMI_IP_Initialize
1315: 885.667 [IMPP] H264E InitializeH264EncodeFor1080pDZoom
1316: 885.741 [IMPP] H264E InitializeH264EncodeFor1080p25fpsDZoom
1352: 906.774 [MR_MOV] (Empty Func) MVW_RegisterXmpDataCallback
1422: 929.689 WARN [LVDS] First Get DTS_GetAllRandomData
1524: 940.646 [GUI] MainEventHandler PROP_QR_DIDNOT_EXECUTE(0)(0)
1570: 945.934 [STARTUP] startupInitializeComplete
1572: 946.095 [MC] cam event guimode comp. 0
1732: 996.044 [MC] cam event guimode comp. 0
1829: 1171.131 [DISP] TurnOnDisplay action Type=0Now here is where I'm stuck. I do not know what the connector is called. This is what it looks like (its not JST):
(https://i.imgur.com/Fqjk4AC.png)
Some more updates:
I was able to find the connector: https://www.digikey.com/en/products/detail/jst-sales-america-inc/A06SUR06SUR32W203A/9947452 (https://www.digikey.com/en/products/detail/jst-sales-america-inc/A06SUR06SUR32W203A/9947452)
Once that was wired in, I was able to enable the bootflag
(https://i.imgur.com/YziB342.png)
Now the fun part begins. Gonna follow @heder's instructions to get a build on QEMU first.
VERY nice, great work here.
I'm temporarily with a 1300D, alongside with the M and the 1200D. Let me know if i can help with anything
A "big step" forward ...
(https://i.imgur.com/seIuUmql.jpg)
This is awesome.
amazing work!
Ok ... I was able to run ML on 1300D...at least start with ML ... I think... but DISP keys, MENU, Play, SET stops working ....
If I hold down the SET button and turn on the 1300D, the buttons work ... and if I enter the menu, I see:
Ver. firmware 1.1.0-ml-off
So ... start ML ...
But if I start normally ... I can't get into ML.
All I have to do is dig...
First boot with ML:
(https://i.imgur.com/W4HY1pwm.jpg)
(https://i.imgur.com/W2aDRy6m.jpg)
... and the first self-test...
(https://i.imgur.com/02DQRL4m.jpg)
"thumbs up" ;D
(https://static.designboom.com/wp-content/uploads/2013/03/thumbsAmmo021.jpg)
Wow this is really cool! I've been lurking here for a long time (2019) but never posted. I'm really excited that you've managed to get this to work. I have a bit of experience programming (though never C and I've also never used QEMU) and a 1300D, so I'd be willing to help. Let me know what I can do, I'd love to use this.
I used ML extensively on my old 550d which I later sold. Got a bargain 1300d a year or so ago and really excited to see ML might be possible on it!
Hey, I tried to find the latest repo for 1300d ML but couldn't. Where is the most recent code?
I believe the same question was answered in the last page.
https://www.magiclantern.fm/forum/index.php?topic=17969.400
I've been watching this since I bought a 1300D in 2018. I put magic lantern on an old powershot and have been looking forward to putting it on my 1300D someday.
Hello!
A working version ... what I tested was intervalometer, which until now after 2-3 frames, I received error 70. Now it works ...I hope :P
If there are others to test ...
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021May13.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021May13.1300D110.zip)
There are still problems to be solved ... but I hope this is the beginning ...
Nice! I missed the file ML-SETUP.FIR at this zip.
Can you send it for us?
I have a canon-1300D with firmware version1.1.1, I tried downdating it to the previous version1.1.0 and 1.0.2 using the utility software, I followed the tutorial in this forum,
at the last step the utility software prompts to press the SET button to update the firmware, but there is no prompts popping up in the camera back screen(even after i close the software prompt by pressing ok button),
do i have to press the SET button in the black screen? or do i have to unplug the device and proceed to software update as usual?
I tried both but neither of them worked,
when I unplug the device and proceeds the software update there is still the older firmware version warning showing up,
when I tried pressing SET button while in the black screen nothing happens, just black screen till I switch the device off.
I am doing everything as said in the tutorial.
Edit: I just noticed this method https://youtu.be/QZys2nZUgIY to downdate the firmware from 1.1.1 to 1.1.0 and it worked.
can some one update this on the general downdate tutorial section?
I would test, but I'm not sure if there's anything I need to do to get it working as it won't install ML. I've installed ML on different cameras before, but this one just won't run the nightly.
Hello, I can test it. I am pretty much noob with ml so can you tell me what should I test and how? And can I brick my 1300d with it?
To users asking to test this build: It doesn't work out-of-the-box!
ATM there is no option to generate a FIR file to enable camera bootflag. ATM enabling bootflag requires a non-standard operation via cam's UART interface. https://www.magiclantern.fm/forum/index.php?topic=7531.msg233933#msg233933
If you know how to do that (I guess if you have to google UART first you don't) you want to contact devs on discord.
To clarify: Only those able to access and handle UART properly will be able to test ML for 1300D in the present state!
And yes: You can damage your cam by doing so.
A new version.
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021May21.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021May21.1300D110.zip)
I activated some menu functions + some software changes.
If you can help me with tests. Thank you.
P.S. I come back with the changes made in the source
New version:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021May26.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021May26.1300D110.zip)
I'm working on getting Picture Transfer Protocol (USB) to enable the boot flag.
Here is a working demo: https://github.com/petabyt/sequoia-ptpy
It's highly unstable, and takes around 30 or so attempts in order to
get a OK response from the camera.
I've only been able to test it on the 1300D, but I think this
might work on all Canon DSLRs.
A new version. I solved the problem with prevent Canon firmware from turning off LiveView after 30 minutes.
It works in both photo and video mode.
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Jun05.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Jun05.1300D110.zip)
Just confirming, the build you're testing is for Firmware 1.1.0 yes?
Wanted to check before I try running it on my 1.2.0 camera and possibly ruin it :)
Yes, 1.1.0.
I also solved the problem with Free Memory:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Jun15.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Jun15.1300D110.zip)
Really happy to see all the progress being made regarding the 1300D.
Was already contemplating buying a 5D for the sole reason of it having more than 3 AEB brackets - an arbitrary software limitation of the 1300D, but luckily this thread (and Alex's commits) keept on giving me hope :D
I also think that Petabytes method of enabling the boot flag is big news - even if it takes multiple attempts; not having to fiddle with the hardware is important for people with no technical know-how like me.
A few days ago, I figured out how to get it working 100% of the time. (I think, at least from my 100 or so stress tests)
(It wasn't a timing error or anything, all I did was append ~30 zeros to the string)
I've also made a portable Windows/Linux front-end: https://github.com/petabyt/mlinstall
Although beware, this command is undocumented and I have yet to see the code behind it. Try at your own risk.
Edit: See the https://www.magiclantern.fm/forum/index.php?topic=26162.msg236153 thread.
Hey guys is there any chance you need help testing this? I have a 1300D and wanted to use it for streaming. I'd love to test out clean hdmi out. I have a capture card I can use to test.
Thanks Petabyte, I have ML running on my T6! The driver replacement in Windows was the only part that challenged me (ptp/usb not found error was a battle)
Question on the ML version.... I'm trying to use the camera as a webcam and need as close to 1920x1080 as possible with clean HDMI. Given the limitations I've read about, 1620x910 is theoretically possible. Is it possible to force that resolution out of the HDMI port while not recording? Right now it only outputs 480p clean HDMI.
Thanks again!
OK So I tried using this and critix's build but the program won't pick up the camera when plugged in through USB. I even tried using Zadig to assign libusb to the camera but that didn't work. I'm on Windows 10 right now, I will try on Ubuntu later and report back to you guys.
Quote from: petabyte on June 29, 2021, 08:44:44 PM
A few days ago, I figured out how to get it working 100% of the time. (I think, at least from my 100 or so stress tests)
(It wasn't a timing error or anything, all I did was append ~30 zeros to the string)
I've also made a portable Windows/Linux front-end: https://github.com/petabyt/mlinstall
Although beware, this command is undocumented and I have yet to see the code behind it. Try at your own risk.
Edit: See the https://www.magiclantern.fm/forum/index.php?topic=26162.msg236153 thread.
Since Windows 10 was having issued, I used a LiveCD of Ubuntu 21 and ran Petabyte's linux tool to enable the bootflag on the camera natively, which worked great. Upon first loading, ROM0 and ROM1 were backed up and things started working. Great job everyone involved!
A quick note while running this today, when performing an autofocus, once the lock is obtained, the display shows "Headphones connected" but nothing seems to be wrong and normal pictures are taken in focus.
Hi all, for some reason I never saw these messages.
Solution for the Windows libusb issue: https://www.magiclantern.fm/forum/index.php?topic=26162.msg236405#msg236405
I had mentioned using Zadig in an earlier release, but I thought the new codebase I
used (ptpcam) fixed this issue (I forgot I had libusb installed in my VM), and never gave it much thought after that.
Hi, I wanna test it in my T6 but I have firmware 1.2.0. Do you guys think it'll still work? I tried to reinstall firmware 1.0 back but I can't manage to do it from EOS Utility software cause it ask me to press a button tha doesn't do anything in Eos T6 neither could intall manually via SD card cause for some reason My Pc won't let me paste files that are not media files in the SD drive when I connect my cam, and I don't have a card reader for my pc. Any help or perhaps a workarround to install the correct firmware version, please? Thanks
Edit: I also tried the battery door method and not worked.
Is there a third party tool to flash stock canon firmware? or I just lost all oportunities to try ML on my cam because the firmware update?
I assume you saw https://www.magiclantern.fm/forum/index.php?topic=17969.msg233693#msg233693 ?
Not sure if you are doing it incorrectly or it doesn't work on your model for some reason.
Also, It may eventually be ported to version 1.2.0.
(https://bitbucket.org/ccritix/magic-lantern-git/src/0dc9b73b37356575460576525de2ca2f8e3e0900/platform/1300D.120/?at=branches%2F1300D (https://bitbucket.org/ccritix/magic-lantern-git/src/0dc9b73b37356575460576525de2ca2f8e3e0900/platform/1300D.120/?at=branches%2F1300D)?)
I put on bitbuchet: https://bitbucket.org/ccritix/magic-lantern-git/src/9f9f97c0917d9cbc1ae91d911a87cdfcff2875bd/?at=branches%2F1300D (https://bitbucket.org/ccritix/magic-lantern-git/src/9f9f97c0917d9cbc1ae91d911a87cdfcff2875bd/?at=branches%2F1300D) and on github: https://github.com/ccl/branches/1300D (https://github.com/ccl/branches/1300D) source I've worked on so far.
ML on 1300D can be tried here:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Sep11.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Sep11.1300D110.zip)
It's not final ... there are still bugs to fix ... and improvements ...
Maybe someone wants to try ... and tell me what errors / bugs are still unresolved so far ... or what's wrong ...
Hii, can we install ml simply with sd card or with "wires"
I have a question regarding your windows program "ML USB Installation tool". I downgraded my 1300D with the battery door method successfully and the programme reads my camera, but the tool itself I'm not to familiar with in the sense of how to use it. Could somone point me in the right direction?
Nevermind, I managed to get magic lantern working on my 1300D!
https://ibb.co/cJHxvQb
I'll do some testing soon and report back. Thank you to the devs whom have put so much time into getting the ball rolling for this camera ✌️
Quote from: denizza on September 11, 2021, 12:34:28 PM
Hii, I want install ml on my 1300d, I just update firmware with this files? https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Sep11.1300D110.zip and that firmware I should be?
Quote from: denizza on September 11, 2021, 05:50:27 PM
You need to downgrade to firmware version "1.1.0" if you're not already on that version. If not then you need to do the battery door method. I might make a video on how to do so with the 1300D as it's a bit different since the sd slot and battery door aren't separate. After that you need to download the "ML installation tool" and follow the steps. If anyone wants I can make a video of the process.
Quote from: petabyte on June 29, 2021, 08:44:44 PM
A few days ago, I figured out how to get it working 100% of the time. (I think, at least from my 100 or so stress tests)
(It wasn't a timing error or anything, all I did was append ~30 zeros to the string)
I've also made a portable Windows/Linux front-end: https://github.com/petabyt/mlinstall
Although beware, this command is undocumented and I have yet to see the code behind it. Try at your own risk.
Edit: See the https://www.magiclantern.fm/forum/index.php?topic=26162.msg236153 thread.
With this you can enable boot flag on device.
Then copy content of zip on sdcard. Power on device...and ML sould work. But...only with firmware 1.1.0
Quote from: critix on September 11, 2021, 06:31:07 PM
With this you can enable boot flag on device.
Then copy content of zip on sdcard. Power on device...and ML sould work. But...only with firmware 1.1.0
Ahh even better! haha
Quote from: critix on September 11, 2021, 06:31:07 PM
With this you can enable boot flag on device.
Then copy content of zip on sdcard. Power on device...and ML sould work. But...only with firmware 1.1.0
I enabled boot flag "Running 'EnableBootDisk' with 0 params...
Length: 0: 0 0 0 0 0"
response code :2001 . return code ok. enabled boot flag.
My sd card was in my laptop with ml, i putted in dslr and tried updated but camera say there is no firmware, and now my sd cant wont load on laptop. help xD
Try like this https://github.com/petabyt/mlinstall/blob/master/assets/zadig.gif (https://github.com/petabyt/mlinstall/blob/master/assets/zadig.gif)
I did it work, I edited post can you help with that
Quote from: denizza on September 11, 2021, 09:19:10 PM
I enabled boot flag "Running 'EnableBootDisk' with 0 params...
Length: 0: 0 0 0 0 0"
response code :2001 . return code ok. enabled boot flag.
My sd card was in my laptop with ml, i putted in dslr and tried updated but camera say there is no firmware, and now my sd cant wont load on laptop. help xD
ML installation on 1300D is a bit different. It doesn't follow the rules for other cams.
You cannot use Canon menu option "Firmware update" to enable ML!
Format your SD-card using the camera. Now you have 2 options to make your card bootable.
First is via USB with card inserted to cam and a command.
Or you use your PC and card inserted into cardreader. For Windows you should use EOScard utility. Then wipe disk contents and copy nightly build for 1300D to card. For macOS you can use MacBoot or Make_bootable.sh. See https://wiki.magiclantern.fm/install#installing_magic_lantern_on_other_cards
Thanks @Walter Schulz
So when I make my sd card bootable with eoscard is ml installed on camera or I should update firmware in camera?
I dont understand "strings" on eoscard. Should I mark all 3 strings "eos_develop", "bootdisk" and "script" And write "0x47/71 on develop"
"0x5c/92 on bootdisk" and "0x1f0 on script"
And I have 2 sd cards, can I normaly swich and use one with ml and 1 without or it will brick camera?
And http://pel.hu/down/EOScard.exe not work to download eoscard xD.
You can not use "Firmware Update" to install ML on 1300D!
Link to EOScard.exe works for me.
Okej I installed ml and it works :D
First, bug (I think) when I focus in live mode I get message "headphone connected" and when press mesu "headphones disconnected
https://drive.google.com/file/d/1MD1UIkXWdVpAyeHQsagImdKAaWGmFpxK/view?usp=sharing
Second, Magic zoom,zebras and focus peaking dont work dont show when recording
https://drive.google.com/file/d/1MYGnBl767T5a7e-qocALRvURX08u6BKA/view?usp=sharing
Third, how to zebras and focus peaking show on taken picture more then 1 secound?
Fourth,can I insert another sd card (without ml) and use camera normaly without brick it?
Quote from: denizza on September 12, 2021, 01:31:38 PM
Fourth,can I insert another sd card (without ml) and use camera normaly without brick it?
https://wiki.magiclantern.fm/faq#can_i_start_my_cam_without_ml is valid for this build, too. As long as it is not a first generation Eye-Fi card.
Quote from: denizza on September 12, 2021, 01:31:38 PM
Okej I installed ml and it works :D
Thanks for replay.
I will try to resolve bugs you found...
Hello,
Thank you all for this work.
Would it be possible to do a tutorial to install it?
thank you so much
Hi,
Just installed and can't seam to get the camera to record video. Is this supposed to be working or am missing something? I'm totally new to ML so it's likely that I'm just missing something basic...
1300D - Firmware 1.1.0
Installed ML using https://github.com/petabyt/mlinstall
Had to use Win LibUSB fix : https://www.magiclantern.fm/forum/index.php?topic=26162.msg236405#msg236405
The install works, however there is a strange issue where it only works in photomodes, not in video. I cannot access the ML menu in video mode, nothing happens. I can adjust aperture etc fine in photomode.
On first (second?) boot it did seem to work but the menu would flicker every 3-4 seconds or so.
Has anyone else had this issue?
Thanks so much for all the hard work on this.
I was going to do a fresh install on my camera and decided to make an installation guide.
https://docs.google.com/document/d/1PdUBSY9Ao1l8G-8axQo4XcFOP-bxDbqWvRK-hcXm0LY/edit?usp=sharing
I've enabled editing for anybody, so feel free to make any edits. Eventually I may add it into the ML wiki.
A new release: https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Oct14.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Oct14.1300D110.zip)
Fix headphone connected
It works now too Magic zoom, zebras and focus peaking.
I'm waiting for you to tell me about other bugs found ;)
critix The link doesn't seem to work. The bitbucket one your posted on the Discord room works, so I'll put my findings here:
One strange thing:
- Enter menu
- Press Q on "Close register log"
- Can't use arrows to navigate menus (a popup should be shown?)
- Press Q again, can navigate menus
Other than than it seems to be working well. Nice job.
Unfortunately, I didn't test the link ... but this is the best one.
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Oct15.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Oct15.1300D110.zip)
I removed the Close register log submenu from the Audio menu because it doesn't work yet.
In the Audio menu, "Test beep sound" is not functional yet. I'm trying to solve this function as well
I found two issues:
- The Temperature-measurement seems wrong. For me it reports 13°C (55F) in a 27°C Room
- Magic Lantern crashes when taking a screenshot. The screenshot gets written to the sd card before the crash (see log on bottom)
Crash log:
ASSERT: FALSE
at ./ASIF/ASIF.c:486, ASIF:fe1066f4
lv:0 mode:0
ASIF stack: 16d7a0 [16d898-16c898]
0xUNKNOWN @ 41fc:16d888
0xUNKNOWN @ fe2c2170:16d860
0xFE2BE970 @ fe105b08:16d838
0xUNKNOWN @ fe2be9a0:16d828
0xUNKNOWN @ fe2bea28:16d808
0xUNKNOWN @ fe288ffc:16d7f0
0x00CD1E90 @ cb83ec:16d7e8
0x00003CBC @ fe1066f0:16d7d0
0x00C80378 @ c809ec:16d7a0
Magic Lantern version : Nightly.2021Oct15.1300D110
Mercurial changeset : NO_HG
Built on 2021-10-15 14:51:32 UTC by root@DESKTOP-D54K2FD.
Free Memory : 256K + 873K
Quote from: petabyte on October 09, 2021, 01:48:57 AM
I was going to do a fresh install on my camera and decided to make an installation guide.
https://docs.google.com/document/d/1PdUBSY9Ao1l8G-8axQo4XcFOP-bxDbqWvRK-hcXm0LY/edit?usp=sharing
I've enabled editing for anybody, so feel free to make any edits. Eventually I may add it into the ML wiki.
Hey I pretty much followed ur instructions to a T but when I put the SD card in my came it won't cut on until I take the SD card out. Looking at your steps vs what I'm seeing on my cam, everything looks the same except when I write the bootflag. That's only difference.
my flags are
EOS_DEVELOPFAT32 3ÉBOOTDISKU1/2
&
BOOTDISKU1/2
Not sure if this is the issue though.
Could you send a screenshot?
Try EOSCard. If that doesn't work, then you probably want to talk with critix.
Try to do a firmware update to version 1.1.0. (even if you have exactly this version on your device). Then you can try to test ML. This problem seems to exist on many devices. I suffered the same with my device. After an "update" to version 1.1.0, I was able to work on ML.
First of all thanks for all the work, I am excited that magic lantern finally works in this camera.
I found a couple of bugs (I think so) ...
1. The magic lantern menu does not open in video mode.
2. If you are in manual mode then you use Live View and open the magic lantern menu the menu will flicker every 3 seconds or so.
3. The option to change the white balance in magic lantern does not work, it stays stuck with the one you put in the canon menu.
4. ML Digital Iso does not work, if you change it the screen will be black and you will record black.
Is ML on 1300d still missing some essential features? Because otherwise this thread would've been stickied, right?
A new version:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov09.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov09.1300D110.zip)
- The temperature measurement / display has been repaired.
- Is displayed in LV focal length.
- White balance can change from ML.
Quote from: elenhil on November 09, 2021, 07:04:57 AM
Is ML on 1300d still missing some essential features? Because otherwise this thread would've been stickied, right?
No. AFAIK stickies in "Camera-specific Development" are representing cams with "official" builds (nightly and experimental).
Thanks for this! I was able to get this build of ML working on my EOS Rebel T6.
Related, I'm trying to use it as a webcam with an Elgato Cam Link 4K but the HDMI output has black bars. Is there a way with Magic Lantern to zoom the output to fill the HDMI output?
critix, some things I noticed:
- In liveview, trash button opens ML, and menus "glitch" every 3 seconds
- Was "fps override" lowercase before? Camera crashes when I enter liveview with it
temperature, lv focal length, and custom white balance are working good.
mltetris.mo and silent.mo seem to be working fine.
Nice work.
Quote from: petabyte on November 13, 2021, 07:55:05 PM
- In liveview, trash button opens ML, and menus "glitch" every 3 seconds
I solved this problem.
I'm going to upload a new version these days.
Quote from: jaxzin on November 09, 2021, 05:50:33 PM
Related, I'm trying to use it as a webcam with an Elgato Cam Link 4K but the HDMI output has black bars. Is there a way with Magic Lantern to zoom the output to fill the HDMI output?
Top of page -> Wiki -> FAQ
I solved the problem reported by @petabyte:
Quote- In liveview, trash button opens ML, and menus "glitch" every 3 seconds
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov24.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2021Nov24.1300D110.zip)
Just wanted to pop in and say thanks to the devs for making this available. On the install part, I could not get it to work the first time around. I did a firmware update to 1.1.0 even though that is what I had, which was earlier recommended, and it works perfectly (so far). Definitely not a pro but if I have any issues I will report them here. Thanks again!
Hello,
First and foremost, thanks to all this community that works so hard. Now, I am trying to install ML on my T6 but I do have the latest firmware and I could not find the way to downgrade it: EOS Utility does not have the firmware feature and if I install multiple versions on a card, the camera won't let me proceed with the firmware install. Does anyone know a way to downgrade?
FYI: I tried with my firmware 1.2.0 and I got a black screen, remove batteries and then works.
In advance, thanks for the advice.
I've been using the latest version of magic lantern (2021Nov24.1300D110) for a week or two now. So happy with the features it's added. I can confirm the menu not loading whilst in video mode exists. Furthermore, the aspect ratio and video resolution displays N/A yet I can still change the aspect ratio but not the resolution. This does change the behaviour of video mode after I've set them and gone back to video mode. I'm using the mlv_rec raw video 2.0 btw. Also other than my sd card being slow? 20mb? Which is making it skip like three quarters of the frames, and the menu issue, it works alright too.
Is there any free software which I can use to process the mlv files coming from it?
Hi!
Don't have anything meaningful to add, just wanted to say I appreciate your efforts very much! Thanks for doing this!
I followed this thread since about a year and I was finally able to test Magic Lantern on my EOS 1300D. Thank you very much for the great work!
I found some bugs relating raw video (which is the reason why I want to use Magic Lantern):
- First, I can confirm that the magic lantern menu does not open in video mode.
- I tried both raw recording options. The module mlv_rec.mo (v.2.0) does not load. mlv_lite (v 1.1) loads but when hitting the record button in video mode I get a message "Occupied.. please wait" on to of the screen and a lot of errors showing: "Data corruption at slot 24".
I am using the newest version magiclantern-Nightly.2021Nov24.1300D110.zip
First timer here and I can't seem to get it to work, I have re-updated firmware to 1.1.0 and followed the directions from this google doc that was posted earlier.
https://docs.google.com/document/d/1PdUBSY9Ao1l8G-8axQo4XcFOP-bxDbqWvRK-hcXm0LY/edit?usp=sharing
Nothing happens when I boot up the camera, I have tried multiple times with re-doing the base firmware and reflashing the Magic Lantern firmware onto the SD. I am not sure what is wrong, desperately needing help can someone walk me step by step to get this to work?
Have you tried pressing the trashcan button?
https://wiki.magiclantern.fm/faq -> Usage
On the 1300D, ML does not use the trash button to enter the menu, but the AV button, because the 1300D does not have a trash button.
Quote from: The Penguin on December 27, 2021, 02:57:58 PM
- First, I can confirm that the magic lantern menu does not open in video mode.
- I tried both raw recording options. The module mlv_rec.mo (v.2.0) does not load. mlv_lite (v 1.1) loads but when hitting the record button in video mode I get a message "Occupied.. please wait" on to of the screen and a lot of errors showing: "Data corruption at slot 24".
To enter the menu in video mode press the AV and SET button at the same time.
The mlv_rec module works perfectly fine from the first day I use it.
For downgrade, please follow:
https://youtu.be/QZys2nZUgIY (https://youtu.be/QZys2nZUgIY)
This confused me enough that I had to look it up.
The 1300D *does* have a Trash button. It doesn't have a dedicated Trash button, it shares the same button as AV.
Yes, you are right. That's how I was supposed to express myself.
Quote from: The Penguin on December 27, 2021, 02:57:58 PM
First, I can confirm that the magic lantern menu does not open in video mode.
I've solved this problem in the meantime. I'm going to release it.
I put a new version of ML for 1300D, which solves the problem of accessing ML in video mode.
The adtg and raw_diag modules also work (I haven't tested it much ... but so far I can see it's okay).
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2022Feb07.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2022Feb07.1300D110.zip)
The ML source is at
https://github.com/ccritix/magic-lantern (https://github.com/ccritix/magic-lantern)
didn't check your code but I implemented a solution back then for OK / SET button on 100D - you can use it just in case you'd still need that
Unfortunately, I don't understand what you mean.
Quote from: critix on February 07, 2022, 10:07:16 AM
I put a new version of ML for 1300D, which solves the problem of accessing ML in video mode.
The adtg and raw_diag modules also work (I haven't tested it much ... but so far I can see it's okay).
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2022Feb07.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2022Feb07.1300D110.zip)
The ML source is at
https://github.com/ccritix/magic-lantern (https://github.com/ccritix/magic-lantern)
First of all: Hello everyone!
So, im new here, read a lot of stuff but i still confused on how do i use this. As far as i could see, theres some files missing at the zip file like the ML_SETUP.FIR
How do i install this build? Thanks!
No ML_SETUP.FIR for this build, sorry. Legal reasons.
Lookup reply #483 for installation guide.
Quote from: Walter Schulz on March 17, 2022, 06:08:36 AM
No ML_SETUP.FIR for this build, sorry. Legal reasons.
Lookup reply #483 for installation guide.
Can I compile it myself?
Quote from: Walter Schulz on March 17, 2022, 06:08:36 AM
No ML_SETUP.FIR for this build, sorry. Legal reasons.
Lookup reply #483 for installation guide.
I am a Chinese pupil，we can't visit Google
Short answer: No.
Try https://wiki.magiclantern.fm/new-install
Quote from: Walter Schulz on March 20, 2022, 02:53:25 PM
Try https://wiki.magiclantern.fm/new-install
How to using firmware version 1.10？
My cam use 1.2.0 version firmware ,I can't "update" to 1.1.0
I can't connect the camera to my computer,
If you can't connect your camera to your computer at all: Sorry, we can't help you!
Most likely you just have to disable wireless options and use a USB cable certified for data transfer. Cables designed for charging only won't work.
Downgrading: First use Canon camera menu option.
If downgrading to 1.1.0 via camera menu doesn't work because camera tells you you are using an older version: Downgrading can be done using the "battery door" method.
https://www.magiclantern.fm/forum/index.php?topic=24926.msg231788#msg231788
Quote from: Walter Schulz on March 20, 2022, 06:06:31 PM
If you can't connect your camera to your computer at all: Sorry, we can't help you!
Most likely you just have to disable wireless options and use a USB cable certified for data transfer. Cables designed for charging only won't work.
Downgrading: First use Canon camera menu option.
If downgrading to 1.1.0 via camera menu doesn't work because camera tells you you are using an older version: Downgrading can be done using the "battery door" method.
https://www.magiclantern.fm/forum/index.php?topic=24926.msg231788#msg231788
It works! I install magic lantern success, and I taken my camera to school, I got some... error logs. If I open the battery door, than close it, I can't normal boot up, it's going to report err 70,but when I half press shutter,it'boot up,I'll send these logs when I go home
How can I adding attachments on this Forum?
Quote from: Calarificus on December 29, 2021, 05:57:52 AM
First timer here and I can't seem to get it to work, I have re-updated firmware to 1.1.0 and followed the directions from this google doc that was posted earlier.
https://docs.google.com/document/d/1PdUBSY9Ao1l8G-8axQo4XcFOP-bxDbqWvRK-hcXm0LY/edit?usp=sharing
Nothing happens when I boot up the camera, I have tried multiple times with re-doing the base firmware and reflashing the Magic Lantern firmware onto the SD. I am not sure what is wrong, desperately needing help can someone walk me step by step to get this to work?
I've tried the exact step as shown but it shows "Memory card containing firmware is required to update"
So you are trying to install Canon's firmware file 1.1.0?
Show card's root directory content.
Guys I today had weird problem, so few months ago I installed ml on 1 sd card, then I bought new sd card (without ml) and used few months, then today I tried to turn on dslr but it didnt work, then I tried to turn on without sd card and it worked, so bassicly camera want boot on with sd card and without it will. So i reset all settings and now works so what was problem? My camera normaly worked few months without ml sd card
Format card on PC and try again.
It works now after i reset settings in dslr
Quotei reset all settings and now works so what was problem?
You've answered your own question. One of the settings was the problem. Which setting? I can't tell you, I don't know what they were.
It's possible for settings to become corrupted. This can happen with or without ML, due to the way Canon saves them. If you can find a repeatable way to hit the problem, and if it's due to ML, then we can try to work out the cause and fix it. If you can't repeat it, there's nothing we can do.
since the 2000d uses the same digic processor, i would like to try and port it to my camera
what resources do I need since I'm only experienced in java?
Hello! I've recently loaded ML onto my Canon Rebel T6! using the "magiclantern-Nightly.2022Feb07.1300D110.zip" Build provided in this forum.
Although "Clear Overlay" works, I do not see any "fps override" in this ML build that i've seen someone mention having in this forum. Does this build have an "fps override" option? and if so, how can i enable it? as i dont see anywhere to enable this option.
I have a problem, if I want to record 10bit or 12bit raw video, Why it will record a black screen?
Video mode not working...now...
Hello everyone! I wanted before everything to thank you guys who are working on this. Thank you so much.
I tried to download and install Magic Lantern on my 1300D/T6 following the guide provided on this topic.
When I insert the battery into the camera, with the switch being in the off position, the red light makes just one blink but nothing else happens even turning on the camera, and the battery drains until it runs out of power.
When I turn on the camera without SD card, it boots normally.
Do you happen to know the reason of this?
Thank you so much in advance for the help, have a good day!
EDIT: i solved by updating the canon firmware first, i thought it was unnecessary because i already had 1.1.0.
Quote from: critix on May 28, 2022, 12:48:27 PM
Video mode not working...now...
How can I help ? I discover err70 error always happen when I running Self tests -> Stubs API test or load dual_iso.mo
Hi everybody.
I tried to start an install from scratch. It says no PTP/USB device found couldn't enable boot disk. When I try to change the drivers like the manual says I don't know what device driver to change. Because the manual is not showing the image https://petabyt.github.io/mlinstall/MANUAL#no-ptpusb-device-found
On the other hand, could you guys make a newly updated referral point with all the steps for a new installation? Thank you for your time and effort
Hi Gabochess, I just fixed the manual link.
https://petabyt.github.io/mlinstall/MANUAL#no-ptpusb-device-found
You might need to do a hard refresh to update the cache (Ctrl+Shift+R)
Hey thank you for your reply. The only driver I can see is WUDFWpdMtp (v10.0.19041.746) no WinUSB. I did a fresh install of the firmware from 1.1.0 to 1.1.0.
Quote from: petabyte on October 09, 2021, 01:48:57 AM
I was going to do a fresh install on my camera and decided to make an installation guide.
https://docs.google.com/document/d/1PdUBSY9Ao1l8G-8axQo4XcFOP-bxDbqWvRK-hcXm0LY/edit?usp=sharing
I've enabled editing for anybody, so feel free to make any edits. Eventually I may add it into the ML wiki.
Hey everyone, I am new to the forum, a friend recommended ML to me and then I discover 1300D isnt properly supported like the other cameras.
I just wanted to give a massive thanks to Petebyte for this brilliant install guide that made it simple to accomplish!! I would also like to say an even bigger thanks to those who help produce the ML mod for the 1300D!! Keep up the great work!
Install tutorial I made: https://youtu.be/oY4RbCaadrc
Hi,
I used the 64 bit version (win64-gtk-mlinstall.zip) from https://github.com/petabyt/mlinstall/releases/tag/0.9.2 and got the data on the SD card ok but when I went to install zadig.exe I am given the notification "This app can't run on your PC - To find a version for your PC, check with the software publisher". Any idea if there is a workaround? Working off a fairly new Windows 10 machine.
Thanks in advance.
Currently figuring out how make it so that mlinstall will work on Windows without Zadig. (Where it's a pain to uninstall libusb)
Option 1:
Use win32-libusb filter installer: https://github.com/mcuee/libusb-win32/releases/download/snapshot_1.2.7.3/libusb-win32-devel-filter-1.2.7.3.exe
Without an installer: https://github.com/mcuee/libusb-win32/releases/download/snapshot_1.2.7.3/libusb-win32-bin-1.2.7.3.zip
Option 2:
Use the native Windows API directly.
- This adds WinUSB support to a libusb-like interface, https://github.com/avrdudes/libusb
- I tried to get WinUSB to connect to my camera, but it wouldn't accept it.
- It might be possible to fork libusb-win32 and patch it to work on a specific GUID (GUID_DEVCLASS_IMAGE)
I am having an issue installing the ml software. Forgot to downgrade my firmware from 1.2.0 and cant seem to get any downgrade options to work. Still connects fine to my pc and is still recognizable, but EOS utility doesnt work which i kinda expected.
Quote from: clarko on August 30, 2022, 01:47:09 PM
.. I went to install zadig.exe I am given the notification "This app can't run on your PC - To find a version for your PC, check with the software publisher". Any idea if there is a workaround? Working off a fairly new Windows 10 machine.
It does work fine here, I am using Windows 10 x64, v21H2, OS build: 19044.2006.
Which Windows 10 version are you using?
Quote from: Niichad on September 28, 2022, 12:25:37 PM
I am having an issue installing the ml software. Forgot to downgrade my firmware from 1.2.0 and cant seem to get any downgrade options to work. Still connects fine to my pc and is still recognizable, but EOS utility doesnt work which i kinda expected.
Sorry, please explain your problem(s) in more detail. It is hard to follow right now.
Quote from: Niichad on September 28, 2022, 12:25:37 PM
I am having an issue installing the ml software. Forgot to downgrade my firmware from 1.2.0 and cant seem to get any downgrade options to work. Still connects fine to my pc and is still recognizable, but EOS utility doesnt work which i kinda expected.
There is an issue upstream with Zadig, which makes the driver near impossible to uninstall. I'm very slowly working on a solution.
You can use the battery door method to downgrade the firmware, see https://www.magiclantern.fm/forum/index.php?topic=24926.0
Eventually mlinstall itself will have a feature that makes it possible to downgrade the firmware over USB.
Working on porting ML to 1300D/T6 firmware version 1.2.0.
https://github.com/petabyt/magiclantern_simplified/commits/1300d
Currently it boots into menus, and passes stubs API test. I'll test it more over the next few weeks.
The plan is to move the codebase to https://github.com/reticulatedpines/magiclantern_simplified,
which is more modern and has some build system fixes.
Finally managed to get EOS Utility working with my camera. Turns out LibUSB wasn't permanently installed, but I had managed to uninstall the Windows MTP driver.
In order to restore this driver, head to C:\Windows\INF\ and right click on the wptmtp.inf, and Cick Install. That, along with uninstalling the LibUSB connection in device manager, should restore everything.
Zadig still seems very janky, slow, and destructive, so I now recommend using the libusb win32 filter installer: https://github.com/mcuee/libusb-win32/releases/download/snapshot_1.2.7.3/libusb-win32-bin-1.2.7.3.zip
The nice thing about it is that you don't need to remove it, I've been able to run EOS Utility and mlinstall at the same time. Not sure if it's stable, but it can work. Probably still a good idea to remove the filter when you're done.
Magic Lantern 1300D 1.2.0: I've been testing this for a while to make sure there aren't any random crashes, and it's worked okay so far.
I updated every single address I could find (and checked all the ifdefs). The code is copied directly from critix's 0.1.0 repository.
Passed self test. I went ahead and deleted a few modules I wasn't confident with, but left mlvlite in. I've recorded a good bit of raw (maybe 10-20 minutes) and I haven't had any issues so far, but I should still warn you, it might break your camera. No guarantees.
EDIT: The 1.2.0 port has been removed. Newer and more stable version will be released in the future.
I've made a few attempts to port the 1300D port to the names_are_hard magiclantern_simplified fork, but the camera crashes after trying to register some property handlers. I probably won't continue trying (no point in doing so), but if anybody else wants to give it a shot: https://github.com/petabyt/magiclantern_simplified/tree/1300d
Quote from: petabyte on January 02, 2023, 03:22:59 AM
Magic Lantern 1300D 1.2.0: I've been testing this for a while to make sure there aren't any random crashes, and it's worked okay so far.
I updated every single address I could find (and checked all the ifdefs). The code is copied directly from critix's 0.1.0 repository.
Passed self test. I went ahead and deleted a few modules I wasn't confident with, but left mlvlite in. I've recorded a good bit of raw (maybe 10-20 minutes) and I haven't had any issues so far, but I should still warn you, it might break your camera. No guarantees.
https://eggnog.theres.life/f/66-ks45fna8sx9si9m3tf6jrgf3uchkkx.zip
I've made a few attempts to port the 1300D port to the names_are_hard magiclantern_simplified fork, but the camera crashes after trying to register some property handlers. I probably won't continue trying (no point in doing so), but if anybody else wants to give it a shot: https://github.com/petabyt/magiclantern_simplified/tree/1300d
I can confirm that it works on my Rebel T6 running 1.2.0, thank you so much! It was a pain downgrading just so I could run magic lantern, but now I don't have to! On 1.1.0 for some reason the colors on the display were warm, maybe Canon added calibration or something? I don't have a colorimeter so I don't know. Anyways, running with the latest firmware is always nice. :D
I just tried critix 0.1.0 version on my 1300D with firmware 1.1.0 and got raw video (without sound and without playback) working on my camera.
Thank you very much for the great work!
I have two questions:
- What is the maximal bitrate you get with the 1300D? Although I have quite fast SD cards, my maximal bitrate was around 20MByte/sec. This means that I only get a few (roughly 4) seconds of 1280 video when reduced to 2:1 and 24fps. Does someone get better results and if yes, what card are you using?
- Is there any advantage for Magic Lantern that I would get by upgrading my camera to firmware 1.2.0 and use Petabyte's Magic Lantern version?
1.2.0 version has no new features.
As for RAW, I wasn't able to get anything that good, only a few seconds of decent footage at a time on my 80mbs SansDisk ultra.
Also, as an update to this thread, I've recently modified mlinstall to work with my camlib/libwpd libraries, which work on Windows natively. No more libusb nonsense soon. Works great on my end, I'll release it once I've done more testing.
Quote from: petabyte on January 02, 2023, 03:22:59 AM
Magic Lantern 1300D 1.2.0: I've been testing this for a while to make sure there aren't any random crashes, and it's worked okay so far.
I updated every single address I could find (and checked all the ifdefs). The code is copied directly from critix's 0.1.0 repository.
Passed self test. I went ahead and deleted a few modules I wasn't confident with, but left mlvlite in. I've recorded a good bit of raw (maybe 10-20 minutes) and I haven't had any issues so far, but I should still warn you, it might break your camera. No guarantees.
https://eggnog.theres.life/f/66-ks45fna8sx9si9m3tf6jrgf3uchkkx.zip
I've made a few attempts to port the 1300D port to the names_are_hard magiclantern_simplified fork, but the camera crashes after trying to register some property handlers. I probably won't continue trying (no point in doing so), but if anybody else wants to give it a shot: https://github.com/petabyt/magiclantern_simplified/tree/1300d
Hi @petabyte
I am a newbie.
Just installed ML 1300D 1.2.0. It works, but there is no
ISO setting/submenu under the
Expo menu:
(https://i.imgur.com/tqmU749.jpeg)
Update:
I tried it in "M" mode.
In the Video mode, the ML menu does not even appear when I press the Delete button.
BR,
Ladislav
Quote from: laheller on April 07, 2023, 07:13:23 PM
Just installed ML 1300D 1.2.0. It works, but there is no ISO setting/submenu under the Expo menu:
ISO feature was disabled, probably several years ago during development: https://github.com/petabyt/magiclantern_simplified/blob/a661de1242e4b892697c6abb665f88380d7c75da/platform/1300D.120/features.h#L38
I don't know if it works or why it's disabled.
Quote from: petabyte on April 08, 2023, 05:06:30 PM
ISO feature was disabled, probably several years ago during development: https://github.com/petabyt/magiclantern_simplified/blob/a661de1242e4b892697c6abb665f88380d7c75da/platform/1300D.120/features.h#L38
I don't know if it works or why it's disabled.
Any chance to enable it and create a test build? I'll take the risk and will test it.
Quote from: laheller on April 08, 2023, 05:55:50 PM
Any chance to enable it and create a test build? I'll take the risk and will test it.
You can remove that line and compile it yourself. In the future I might look into it.
Quote from: petabyte on April 09, 2023, 02:45:45 AM
You can remove that line and compile it yourself. In the future I might look into it.
This is potentially dangerous advice.
Enabling the feature will cause ML to write to registers. If these addresses have changed it could permanently damage the camera.
Do not enable this feature unless you have verified the register values still hold for the new cam.
E.g. here in lv-img-engio.c, EngDrvOutLV() triggers writes:
25 #define SHAD_GAIN 0xc0f08030 // controls clipping point (digital ISO)
26 #define SHAD_PRESETUP 0xc0f08034 // controls black point? as in "dcraw -k"
27 #define ISO_PUSH_REGISTER 0xc0f0e0f8 // like display gain, 0x100 = 1 stop, 0x700 = max of 7 stops
...
827 #ifdef FEATURE_EXPO_ISO_DIGIC
828 if (mv)
829 {
830 if (digic_iso_gain_movie_for_gradual_expo == 0) digic_iso_gain_movie_for_gradual_expo = 1024;
831 int total_movie_gain = DIGIC_ISO_GAIN_MOVIE * digic_iso_gain_movie_for_gradual_expo / 1024;
832 if (total_movie_gain != 1024)
833 {
834 autodetect_default_white_level();
835 int boost_stops = 0;
836 int new_gain = get_new_white_level(total_movie_gain, &boost_stops);
837 EngDrvOutLV(SHAD_GAIN, new_gain);
838 shad_gain_last_written = new_gain;
839 #ifndef CONFIG_DIGIC_V
840 EngDrvOutLV(ISO_PUSH_REGISTER, boost_stops << 8);
841 #endif
842 }
Quote from: names_are_hard on April 09, 2023, 03:11:56 AM
This is potentially dangerous advice.
Enabling the feature will cause ML to write to registers. If these addresses have changed it could permanently damage the camera.
Do not enable this feature unless you have verified the register values still hold for the new cam.
E.g. here in lv-img-engio.c, EngDrvOutLV() triggers writes:
25 #define SHAD_GAIN 0xc0f08030 // controls clipping point (digital ISO)
26 #define SHAD_PRESETUP 0xc0f08034 // controls black point? as in "dcraw -k"
27 #define ISO_PUSH_REGISTER 0xc0f0e0f8 // like display gain, 0x100 = 1 stop, 0x700 = max of 7 stops
...
827 #ifdef FEATURE_EXPO_ISO_DIGIC
828 if (mv)
829 {
830 if (digic_iso_gain_movie_for_gradual_expo == 0) digic_iso_gain_movie_for_gradual_expo = 1024;
831 int total_movie_gain = DIGIC_ISO_GAIN_MOVIE * digic_iso_gain_movie_for_gradual_expo / 1024;
832 if (total_movie_gain != 1024)
833 {
834 autodetect_default_white_level();
835 int boost_stops = 0;
836 int new_gain = get_new_white_level(total_movie_gain, &boost_stops);
837 EngDrvOutLV(SHAD_GAIN, new_gain);
838 shad_gain_last_written = new_gain;
839 #ifndef CONFIG_DIGIC_V
840 EngDrvOutLV(ISO_PUSH_REGISTER, boost_stops << 8);
841 #endif
842 }
Didn't know that. Thanks for letting me know.
Always check what code is surrounded by CONFIG or FEATURE ifdefs - it's often weird or potentially dangerous, that's why it's behind a flag. We run into this a lot trying to port to Digic 6, 7, 8, X. The old code assumes all cams will have stuff at the same addresses because D4 and 5 were quite similar. So, sometimes it just hardcodes a constant in a source file, with no guards.
1300D is what, D4+? Probably fairly similar, but I'd expect some changes. Plus it's a later model and sometimes things change without a digic version change, but because Canon used some different component on the board later on, etc.
This kind of stuff is why I think the 1300D build needs a lot more testing, methodically, of every feature, with uart connected to get better logs. It's almost certainly got some serious bugs.
For anybody wanting to take up development for this port:
Critix's current repository for v1.1.0 is here: https://github.com/ccritix/magic-lantern
My v1.2.0 fork of his code is here: https://github.com/petabyt/magiclantern
It's been a long time since I worked on the v1.2.0 port, and I believe I lost some of my bug fixes I had worked on after wiping my old laptop. Since then I've been busy with many other things, and no longer can work on ML ports. I'll continue to maintain mlinstall (https://github.com/petabyt/mlinstall) and the PTP library it uses. I've been using my port for light photography and haven't had any crashes, but it still is mostly untested. The current build fails a self test because of cache issues. I think I remember fixing it, but I still have the issue on the last backup I had made.
I have added a new version for 1300D which solves the error display problem if the firmware version is not the correct one. The rest of the devices displayed an error message, but this device is more atypical.
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2023Sep30.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2023Sep30.1300D110.zip)
I think the same should be done for the 2000D and 4000D (I haven't checked, but since they are similar devices, I think it would be the same)
Sounds interesting - what's the code change? I don't see any updates to the repo (makes it hard to apply to other cams :) )
Here is what I changed in the code:
https://github.com/ccritix/magic-lantern/commit/9d19cd581aea69d7a8d4f8f0de2543d2f4bf48e0
Thanks. I'm having trouble understanding these changes. You're searching a different range, but there's no comment explaining why. Did the bootloader move? How should 2000D / 4000D devs know if or why these changes are required on their cams?
(Also you've mixed tabs and spaces so the formatting is kind of messed up)
From fw-signature.h:
Quote#define SIG_1300D_110 0x3d8461b5 // from FE0C0000 (atypical)
For the rest of the devices, the signature is from FF010000 (ROMBASEADDR = 0xFF010000 from ex: 1100D/Makefile.platform.default)
On 1300D it is at FE0C0000 (ROMBASEADDR = 0xFE0C0000 from 1300D/Makefile.platform.default)
On 2000D: ROMBASEADDR = 0xFE0C0000, so it must be like on 1300D
I meant the search range change, here:
#if defined(CONFIG_1300D)
for (uint32_t i = 0xFE000000; i < 0xFF000000; i += 4 )
#else
for (uint32_t i = 0xFFFE0000; i < 0xFFFFFFF0; i += 4 )
#endif
And here:
#if defined(CONFIG_1300D)
if (func_addr > 0xFE000000)
#else
if (func_addr > 0xFFFE0000)
#endif
I have no way of knowing why these changes are required.
I see. In that case, would it make more sense to define an address for the bootloader somewhere in platform/cam dirs? That way, you wouldn't need a special case for 1300D (which is hard to understand), and instead would have something like this:
for (uint32_t i = BOOTLOADER_BASE_ADDR;
i < BOOTLOADER_BASE_ADDR + 0x1fff0;
i += 4 )
Hi,
I am a new at this forum :). I want to install Magic lantern on my EOS1300. I want to ask, which version i should use.
Thanks to everyone who developt this!
We have some reservations right now with 1300D builds.
What do you want to do with ML?
Hello,
I want to use it for filmmaking with my atomos.
Thanks Walter Schulz for your answer.
Quote from: LWL-Photographie on September 20, 2023, 06:47:12 PM
I want to use it for filmmaking with my atomos.
This should be quite easy and looks like little risk involved.
ML can do clean HDMI out (no overlays). And 30 minute limit can be avoided, too.
But ML can do nothing about cam's HDMI specs. Cam gives 1620x912 active area embedded in 1080i59.94 with 8 bit, 4:2:0 chroma subsampling.
If this matches your needs and expectations it really doesn't matter that much which build you want to install.
Thanks Walter,
Do you have some advices for me how to install it? I never done this before...
Covering ccritix's build for 1300D/T6 firmware 1.1.0
Here we go for Linux and Windows:
Ingredients:
Cam running Canon firmware 1.1.0
1 PC running Windows 10/11 or Linux
USB cable to connect PC and 1300D (Mini-USB Type B)
Cardreader
SDcard
Internet connection
Camera preparation:
You need to have 1.1.0 firmware installed. If you have to upgrade visit https://eoscard.pel.hu and download v110-t6-1300d-x80-win.zip. It is just a zipped file so ignore "win" in name. Just run with install guide included in zip.
You can downgrade, too. It may take some weird looking trick to do so. I case cam denies downgrade: Rollback tutorial by Hari https://www.magiclantern.fm/forum/index.php?topic=24926.msg231788#msg231788
While not mandatory I suggest to disable wireless features and startup cam in photo mode M. With a battery loaded properly.
Card preparation:
For HDMI streming you don't need a fast card. And ML doesn't need much space. Even 256 MByte would do fine.
Full size SD or microSD with adapter: ML doesn't care.
Format card in cam.
Downloads:
https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2023Sep04.1300D110.zip
https://github.com/petabyt/mlinstall/releases
Pick your MLinstall package according to your OS. Windows (if not ancient) should run with win64 version.
- Run MLinstall
-- Windows: Extract zip to a proper location. Startup MLinstall as Admin. Most likely a messade "Windows protected your PC" will pop up. Select "More info" then "Run anyway".
-- Linux: Lookup how to enable AppImages on Linux PCs.
Installation steps for camera:
Connect cam and PC using USB cable.
Startup cam (if not already up and running). Check battery level!
Select USB tab in MLinstall.
Press "Get Device Info". You should get status info below telling you Manufacturer, Model, DeviceVersion and a cryptic SerialNumber. If you don't get this info on first try you may change USB port and/or check if other ptgrams like EOS Utility are running and hijacked/blocked cam. Terminate/stop such programs.
Redo until you get a proper connection! This is mandatory!
If (and only if) your cam is detected in MLinstall: Press "Enable Boot Disk".
Done. You can remove USB connection.
Installation steps for card:
Connect cardreader to PC.
Insert card.
Check if card is connected/mounted properly to your PC's OS.
If so: Press "Write card boot flags".
After this step you may close MLinstall.
Copy extracted build content to card.
Check card content:
- DCIM
- MISC
- ML
- autoexec.bin
If it looks like this: unmount and card.
Done.
Running ML the first time:
Shutdown camera
Insert card
Close compartment door
Startup cam. Wait for LED activity to end.
After standard Canon interface appears: Press trashcan button to access ML menus.
Remarks:
- If startup fails you have to remove battery and try to startup without card.
- After opening card door wait a few seconds before removing card. Canon firmware will access card and it doesn't make a difference if power switch is on or off.
- At first ML startup cam will write a ROM dump to card. Backup content of ML/LOGS!
- Have fun!
Thanks for your advices... you helped me a lot!
Thank you for your help! Can you help me a little more?
I did everything you said, but when I turn on the camera, says more or less this: "Looks like this is not a 1300D, with firmware 1.1.0" etc.
My camera is a T6, I installed the 1.1 firmware like learned in this ML forum, the instalation was completed 100%. Anything I could did wrong for this error message? Any fix for this?
My reason to install ML is the "Clean HDMI" and maybe the "30 minutes shutdown timer" for use in my Podcast Studio.
Please clear up information:
"I installed firmware 1.1 like learned ...". Did you install *Canon Firmware 1.1.0" or are you talkimg about ML build (which is not firmware)?
Startup cam without card inserted and check firmware information in Canon menu.
Quote from: Walter Schulz on September 27, 2023, 11:32:46 PM
Please clear up information:
"I installed firmware 1.1 like learned ...". Did you install *Canon Firmware 1.1.0" or are you talkimg about ML build (which is not firmware)?
Startup cam without card inserted and check firmware information in Canon menu.
Canon Oficial Firmware 1.1.0. In the camera shows 1.1.0 too. In this video he shows a new program I did not used: "Zadig" Should I do like in this video or ignore this cause its not necessary anymore?
Print of the camera:
https://drive.google.com/file/d/1QPN8bP-Z0_kRQR__2YuWZB7vR_MbzPUj/view?usp=drive_link
I made again steps by the first, same error.
Magic Lantern says: Model detection error.
Your camera does not look like a 1300D 1.1.0
On my camera I have the firmware version 1.1.0. and it is a canon eos 1300D.
Did anyone know what I should do?
Quote from: LWL-Photographie on September 29, 2023, 08:23:26 PM
Magic Lantern says: Model detection error.
Your camera does not look like a 1300D 1.1.0
On my camera I have the firmware version 1.1.0. and it is a canon eos 1300D.
Did anyone know what I should do?
I have same problem after folowing these steps. Created a topic here in the fórum, come https://www.magiclantern.fm/forum/index.php?topic=27033.0
I deleted the magiclantern-Nightly.2023Sep04.1300D110.zip version due to build issues.
The functional version is: https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2023Sep30.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2023Sep30.1300D110.zip)
When I follow your Link Bitbucket says:
You do not have access to this repository.
To access this page, you may need to log in with another account. You can also return to the previous page or go back to your dashboard
Try now.
Quote from: critix on September 30, 2023, 06:51:43 PM
I deleted the magiclantern-Nightly.2023Sep04.1300D110.zip version due to build issues.
The functional version is: https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2023Sep30.1300D110.zip (https://bitbucket.org/ccritix/magic-lantern-git/downloads/magiclantern-Nightly.2023Sep30.1300D110.zip)
It works very well!
I think there is a bug in the video mode. The camera reverses red and blue...
The video mode on this device does not work, it has many bugs. I haven't worked on the video part yet.