Canon EOS 1300D / Rebel T6

[adamnock]

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

[adamnock]

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?

Code: [Select]

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
>>


[a1ex]

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.

[electrohead]

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?

[adamnock]

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

[kennetrunner]

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

[kennetrunner]

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'

Code: [Select]

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)



[a1ex]

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 (first comments) and the MPU communication 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 (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).

[kennetrunner]

For info on the 'spells', see mpu.c (first comments) and the MPU communication 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...

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 (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... ??

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

[a1ex]

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.

Struggling here - not seeing a 'hello world' in the minimal directory ?

Code: [Select]

cd minimal/60D.111
cat Makefile
make
locate minimal.c
cd ../..
grep -nri "hello, world" .


[kennetrunner]

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...

[a1ex]

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

[dfort]

@kennetrunner

Totally off topic but noticed your avatar:


I work at DreamWorks Animation part-time so when I open this topic it looks like I'm actually working. 

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.

[kennetrunner]

Yes, your tips have been very helpful @dfort - thanks - and thanks to @a1ex for all the pointers too...

[kennetrunner]

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

Code: [Select]

./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

[a1ex]

-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:

Code: [Select]

./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; for example:

Code: [Select]

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.

[kennetrunner]

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

[kennetrunner]

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

[kennetrunner]

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

[nikfreak]

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?

[kennetrunner]

do 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) :

Code: [Select]

    // 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:

Code: [Select]

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

[kennetrunner]

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.



Ultimately it still crashes, but that is 'expected' as the qemu EOS stuff does not support 'reads'.

This 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...

[dfort]

Cool.


Sent from my iPhone using Tapatalk

[a1ex]

A summary of the recent IRC discussions.

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.

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.

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 ?

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:

Code: [Select]

macro define CURRENT_TASK 0x31170
macro define CURRENT_ISR  (*(int*)0x31174 ? (*(int*)0x640) >> 2 : 0)

Also, to see tasks starting:

Code: [Select]

# 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).

hello world

Code: [Select]

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/

[kennetrunner]

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 ?