Canon 1000d / Rebel XS

[Levas]

There is little to none for the 1000d.
Syscal did some important first steps, but nothing near a working port.
There is nothing yet, no Magic Lantern menu not a single Magic Lantern function etc.

Best way to make use of Magic Lantern is to buy another Canon DSLR which is compatible with Magic Lantern.
Click the 'Downloads' button at the top of this page and go to the 'Nightly builds' here you can see which camera's are supported.
Many of them are released many years ago, second hand they're really affordable.
Some are better supported then others (depending on the user base and if active developers support them) I believe the Classic Canon EOS-M is one of the better supported cheap cams.



 

[intruderj]

1000D is such a great backup camera. It's sad to see the development was discontinued halfway..
Sad to see such a nice cam go down in history without anything to it's name.

It's 2018, but ML on this camera would still be awesome.
@Syscal Any updates on development?

[a1ex]

http://wiki.magiclantern.fm/faq#any_progress_on_xyz

Development has not been discontinued - everything from the QEMU branch is tested on the 1000D firmware, too! (along with ~20 other models able to run the GUI, and ~10 models not there yet)

I'm simply unable to take care of all these cameras alone (at least not in a timely fashion). It's now up to the community to follow our porting guides and do something about it

[intousgrota]

Any news on the progress?

[SysCall]

It looks like nobody is working on it at the moment. I did in the past but took a break.

a1ex still looking on the emulations side I guess.

I'm starting to looking into it again, from time to time.

Don't expect anything in the near future, but you can always join and help changing that

[aprofiti]

I had a look into this a couple of weeks ago, because I could have possibility to get a 1000D at a nearly bargain price which would be fun to play with it and learn how to reverse code.
So I found a dump of 1.0.5 to run into Qemu and started to analyze it.

However, while trying to find some stubs, I have noticed different patterns into disassembled code of 1000D compared to more recent cameras (50D)
Even simple stubs which can be found searchng for strings and then go up a couples of lines, they get hard to track for the function’s entry point.

Having a dump of a 40D or 450D syde by side to 1000D could help understanding what to look for stubs and get development at the same point of the other two.

[aprofiti]

Had some fun yesterday hunting for stubs and I noticed that I can find the same code at different address which differ by an offset...

This is using disassembply.pl with argument "0xFF000000":

Code: [Select]

NSTUB(0xFF4D6F1C, _FIO_GetFileSize)
NSTUB(0xFF4D5D1C, _FIO_OpenFile)
NSTUB(0xFF4D6C40, FIO_ReadFile)
NSTUB(0xFF4D6B7C, _FIO_RemoveFile)
NSTUB(0xFF4D6DB0, FIO_WriteFile) //CF_Test.bin

This is what I get if I use "0xFF800000" as argument to disassemble.pl. To a quick look it sems to match IDA Disassembly when hunting for loc_xxxxx (the are named sub_xxxx instead).

Code: [Select]

NSTUB(0xFF960420, CreateDialogBox)
NSTUB(0xFFD0D5F4, DryosDebugMsg)
NSTUB(0xFFCD6E68, FIO_FindClose)
NSTUB(0xFFCD6E68, FIO_CloseFile)
NSTUB(0xFFCD7090, _FIO_CreateDirectory)
NSTUB(0xFFCD6AB8, _FIO_CreateFile)
NSTUB(0xFFCD67E8, FIO_FindNextEx)
NSTUB(0xFFCD6F1C, _FIO_GetFileSize
NSTUB(0xFFCD5D1C, _FIO_OpenFile)
NSTUB(0xFFCD6C40, FIO_ReadFile)
NSTUB(0xFFCD6B7C, _FIO_RemoveFile)
NSTUB(0xFFCD6DB0, FIO_WriteFile) //tracing "CF_Test.bin"
NSTUB(0xFF865060, GUI_Control)
NSTUB(0xFF896184, GUI_GetFirmVersion)
NSTUB(0xFF8DD5DC, GuiEdLedBlink)
NSTUB(0xFF8DD5AC, GuiEdLedOff)
NSTUB(0xFF8DD57C, GuiEdLedOn)
NSTUB(0xFFD05708, msleep)
NSTUB(0xFFD05A54, task_create)
NSTUB(0xFF887050, SetGUIRequestMode) //not sure - take more argument but has same code pattern
Is code in ROM duplicated also into other smaller range instead of 0xF8000000? Do I need to prefer the second range?

What I do is using 40D's dump and stubs address to find what appears to be the same address into 1000D's disassembly, hunting for function starting with same arguments number and similar refs number, near strings or particular instructions.

Is this method of code pattern matching valid? How can I use qemu to help me in this stage?

[a1ex]

Yes, there are multiple copies of the same ROM; g3gg0 explains how it works here. QEMU also prints the memory map, so you can see where these copies are. See the Initial firmware analysis section in the RE guide.

You need to pick the address used by Canon code. Example for msleep:

Code: [Select]

./run_canon_fw.sh 1000D,firmware="boot=0" -d calls |& grep 05708

 call 0xFFD05708(64, 0, 1, c022011c)                                             at [tHotPlug:ff813224:ffd2f5d8]
...

How to read this:
- Canon code called the function 0xFFD05708 (so that's the one you should pick for stubs) from their HotPlug task, at PC=ff813224 and LR=ffd2f5d8 (go to these addresses in the disassembly to find out the caller code)
- first argument is 0x64 = 100 ms
- the call trace prints the first 4 arguments (R0-R3), but doesn't attempt to find out how many are actually used
- we already know the signature of msleep (from dryos.h: it takes only one argument, so the others should be ignored)

There are many QEMU examples in the EOS M2 thread; however, call trace support for VxWorks is not the best (it crashes quicky because it doesn't know how VxWorks performs task switching). I have a draft patch to get the current task ID, but for some reason, that doesn't seem to fix the warnings (maybe task IDs are reused? didn't look too much into it).

[aprofiti]

Done more patterns matching and got more stubs:

Code: [Select]

NSTUB(0xFFD0C558, CreateRecursiveLock) // **"CreateRecursiveLock"
NSTUB(0xFFD04B74, AcquireRecursiveLock)
NSTUB(0xFFD04C9C, ReleaseRecursiveLock) // AJ_KernelDry_KerRLock.c_p2
NSTUB(0xFFD05330, give_semaphore)
NSTUB(0xFF867778, gui_change_lcd_state_post)
NSTUB(0xFF866BEC, gui_change_mode)
NSTUB(0xFF8676B8, gui_change_shoot_type_post)
NSTUB(0xFF8645FC, gui_init_end)
NSTUB(0xFF8B6344, gui_init_event) // to be checked
NSTUB(0xff866fb8, gui_local_post)
NSTUB(0xff864aec, gui_main_task) // jump in the middle of procedure
NSTUB(0xff865808, gui_massive_event_loop) // similar to 40d
NSTUB(0xff867454, gui_other_post) // similar to 40d
NSTUB(0xff8675e8, gui_post_10000062) // to be checked
NSTUB(0xff95eb24, gui_task_create)
NSTUB(0xff95ec74, gui_task_destroy)
NSTUB(0xffd03694, gui_timer_something)
NSTUB(0xffd1cc88, AllocateMemory)
NSTUB(0xffd1cc88, _AllocateMemory)
NSTUB(0xffd1ccc8, FreeMemory)
NSTUB(0xffd1ccc8, _FreeMemory)
NSTUB(0xff97fd54, RedrawDisplay) // to be checked
NSTUB(0xffd18028, alloc_dma_memory) // takes one less parameter
NSTUB(0xffd18028, _alloc_dma_memory) // takes one less parameter
NSTUB(0xffd1ccc8, free) // not good points to FreeMemory
NSTUB(0xffd1ccc8, _free) // not good points to FreeMemory
NSTUB(0xffd56d2c, free_dma_memory)
NSTUB(0xffd56d2c, _free_dma_memory)
NSTUB(0xffd1cd98, GetMemoryInformation) // to be checked
NSTUB(0xFFD20B28, AllocateMemoryResource) // m_pfAllocMemoryCBR
NSTUB(0xFFD20B7C, AllocateContinuousMemoryResource) // m_pfContAllocMemoryCBR
NSTUB(0xFFD20BD0, FreeMemoryResource) // m_pfFreeMemoryCBR
NSTUB(0xFFD0931C, GetFirstChunkFromSuite) // AJ_PackMemory_PackMem_p3
NSTUB(0xFFD09154, GetMemoryAddressOfMemoryChunk)
NSTUB(0xFFD0C1A4, msg_queue_create) // **"CreateMessageQueue"
NSTUB(0xFFD046C0, msg_queue_post)
NSTUB(0xFFD03FDC, msg_queue_receive)

NSTUB(0xFFD0E6F8, vsnprintf) // to be checked
NSTUB(0xff8d9430, ErrForCamera_handler)  // jump in the middle of procedure // ERR70 ERR80 etc (DlgErrForCamera.c AJ_DIALOG.HANDLER_DlgErrForCamera.c)
NSTUB(0xff8c4f34, LiveViewApp_handler) // used procedure entry point instead jumping in the middle like 40d (to be checked)
NSTUB(0xff8a9bb8, PlayMain_handler) // jump in the middle of procedure
NSTUB(0xffc74fac, BmpDDev_give_semaphore)
NSTUB(0xffc74f5c, BmpDDev_take_semaphore)
NSTUB(0xFFD04DA0, create_named_semaphore)
NSTUB(0xFFD05194, take_semaphore)

NSTUB(0xFFD31D8C, get_current_task)
NSTUB(0xFFD05C60, DeleteTask)
//NSTUB(0xFFD0062C, QueryTaskByName) // taken 40d pattern but jump in the middle of procedure
NSTUB(0xffd10074, create_task_cmd_shell)
NSTUB(0xffc3ecf4, _prop_cleanup) // similar, to be cheched
NSTUB(0xffc3ebd0, prop_register_slave)
I noticed that some stubs jump in the middle of a procedure and starts with a push to the stack. Is this correct?
Also some stubs form 40d like "malloc" and "free" have a comment stating "not good, points to FreeMemory/AllocateMemory" What need to be done?

Adding those stubs and this is what I currently get if I try to compile:

Code: [Select]

[ LD       ]   magiclantern
menu.o: In function `beta_should_warn':
menu.c:(.text+0xa3c): undefined reference to `LoadCalendarFromRTC'
menu.o: In function `handle_ml_menu_keys':
menu.c:(.text+0x7064): undefined reference to `LoadCalendarFromRTC'
gui.o: In function `ml_hijack_gui_main_task':
gui.c:(.text+0x264): undefined reference to `QueryTaskByName'
bmp.o: In function `set_ml_palette_if_dirty':
bmp.c:(.text+0x9d0): undefined reference to `PB_Palette'
config.o: In function `config_save_file':
config.c:(.text+0x7dc): undefined reference to `LoadCalendarFromRTC'
tweaks.o: In function `tweak_task':
tweaks.c:(.text+0xc): undefined reference to `LoadCalendarFromRTC'
lens.o: In function `clock_update':
lens.c:(.text+0x4f0): undefined reference to `LoadCalendarFromRTC'
bootflags.o: In function `bootflag_write_bootblock':
bootflags.c:(.text+0x238): undefined reference to `cf_device'
dialog_test.o: In function `get_current_dialog_handler':
dialog_test.c:(.text+0x14): undefined reference to `gui_task_list'
shoot.o: In function `display_idle':
shoot.c:(.text+0x368): undefined reference to `ShootOlcApp_handler'
zebra-5dc.o: In function `tic':
zebra-5dc.c:(.text+0xe08): undefined reference to `LoadCalendarFromRTC'
make: *** [magiclantern] Error 1
Solved most missing reference but "LoadCalendarFromRTC" is hard to track and I'm not sure about "QueryTaskByName"

Code: [Select]

// From 40D's stubs.s
//NSTUB(0x4AF8, gui_task_list)
//NSTUB(0x17530, gui_main_struct)
//NSTUB(0x314F8, cf_device)
//NSTUB(0x309C8, PB_Palette)
//NSTUB(0x2B24, task_max)
How can I find those RAM address?

Looking 40D "cstart" and "bzero32" are not used in stubs.s nor is warning during 1000D compilation. Does it need to be found at this stage or can get a working build to be run into qemu?
I need some time to read again M2 thread and look for something to try into emulation.

[a1ex]

LoadCalendarFromRTC: try FFCFDA6C

cstart/bzero32 probably not needed (VxWorks model use a different method).

Need to do some digging to find the others.

[SysCall]

When I try to run QEMU, I get only a gray image.

Code: [Select]

./run_canon_fw.sh 1000D,firmware=boot=1

DebugMsg=0xFFD0D5F4 (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 - 0FFFFFFF: eos.ram
10001000 - 1FFFFFFF: eos.ram_uncached
10000000 - 10000FFF: eos.ram_uncached0
F8000000 - F87FFFFF: eos.rom1
F8800000 - F8FFFFFF: eos.rom1_mirror
F9000000 - F97FFFFF: eos.rom1_mirror
F9800000 - F9FFFFFF: eos.rom1_mirror
FA000000 - FA7FFFFF: eos.rom1_mirror
FA800000 - FAFFFFFF: eos.rom1_mirror
FB000000 - FB7FFFFF: eos.rom1_mirror
FB800000 - FBFFFFFF: eos.rom1_mirror
FC000000 - FC7FFFFF: eos.rom1_mirror
FC800000 - FCFFFFFF: eos.rom1_mirror
FD000000 - FD7FFFFF: eos.rom1_mirror
FD800000 - FDFFFFFF: eos.rom1_mirror
FE000000 - FE7FFFFF: eos.rom1_mirror
FE800000 - FEFFFFFF: eos.rom1_mirror
FF000000 - FF7FFFFF: eos.rom1_mirror
FF800000 - FFFFFFFF: eos.rom1_mirror
C0000000 - CFFFFFFF: eos.iomem
[EOS] loading './1000D/ROM1.BIN' (expected size 0x00800000, got 0x00400000) to 0xF8000000-0xF83FFFFF
[MPU] warning: non-empty spell #14 (PROP_CARD2_STATUS) has duplicate(s): #51
[MPU] warning: non-empty spell #34 (PROP_TFT_STATUS) has duplicate(s): #33 #43 #44
[MPU] warning: non-empty spell #42 (PROP_TFT_STATUS) has duplicate(s): #24 #29 #32 #74

[MPU] Available keys:
- Arrow keys   : Navigation
- PgUp, PgDn   : Sub dial (rear scrollwheel)
- [ and ]      : Main dial (top scrollwheel)
- SPACE        : SET (press only)
- DELETE       : guess (press only)
- M            : MENU (press only)
- P            : PLAY (press only)
- I            : INFO/DISP (press only)
- J            : JUMP (press only)
- D            : Direct Print
- W            : Pic.Style (press only)
- Z/X          : Zoom in/out
- Shift        : Half-shutter
- 0/9          : Mode dial (press only)
- B            : Open battery door
- C            : Open card door
- F10          : Power down switch
- F1           : show this help

Setting BOOTDISK flag to FFFFFFFF
It looks like this is the problem:

Code: [Select]

[EOS] loading './1000D/ROM1.BIN' (expected size 0x00800000, got 0x00400000) to 0xF8000000-0xF83FFFFF
I did split the ROM.BIN dump in two equals ROM0.BIN and ROM1.BIN as mentioned in the EOS M2 thread.

8388608 ROMDUMP.BIN
4194304 ROM0.BIN
4194304 ROM1.BIN

Does anyone knows how to fix this?

[a1ex]

Try loading it as ROM1, without splitting.

When following instructions from elsewhere, consider the context. The dumper that saves a file named (NULL) includes both ROMs in the same file (so it has to be split). The 1000D dumper runs:

Code: [Select]

  int handle = FIO_CreateFile("B:/ROMDUMP.BIN");
  FIO_WriteFile(handle, (void*)0xFF800000, 8*1024*1024);
  FIO_CloseFile(handle); 

Compare the above with the memory map (from QEMU log) and expected size.

[SysCall]

Thanks a lot.

This does the trick:

Try loading it as ROM1, without splitting.

Btw, if anyone found an old ROM dump of the 1000D Firmware 1.0.5 on the internet and want to test in QEMU, renamed it to ROM1.BIN as mentioned above.

It was created the same way a1ex explained.

Both firmwares 1.0.5 and 1.0.7 are running in QEMU.

[aprofiti]

Code: [Select]

PB_Palette - the one maybe I need?
bmp_vram_real() - in bmp.c same as above
bmp_vram_info - should not be necessary as isn't asked during compilation if I remember correctly
sd_device - probably minor priority

How to find ram address for those?

I made a quick test defining CONFIG_40D (to solve some minor problems following difference in code for the others cameras running vxworks) and got a compilation without errors but no signs of ML getting loaded in qemu as it doesn't replace firmware version number and it doesn't draw ML Menu.

So I expect to find those pieces to be able to print text and draw ML menu.

Also tried to match gui_task_list from 40D using

Code: [Select]

./run_canon_fw.sh 40D,firmware="boot=0" -d ram and managed to found which subroutine return the value found into stubs.S, done the same with 1000D and also found what to appears the same code in rom's dump but as the function's address is called more than one times and return different values each time, i checked for the same value for 1000D and it shows up in console but not use if is correct to use it...

[Falco361]

Hello im new go this stuff but i was hoping to achieve the build for 1000d or firmwares i beef messing around with it and. Manged to get. 1.0.6 firmware onto the camera.  And i usded a 6d. Build. One that i could only get to do. Was magic lantern. Rescue i took images of it. But i have no clue what it does ir anything. Could anyone give me a hand on where. I obtain the factory firmware or a build that works got the eos xs 1000d