Author Topic: Canon 1000d / Rebel XS  (Read 68128 times)


  • Hero Member
  • *****
  • Posts: 1058
  • 6d - Nightly build user
Re: Canon 1000d / Rebel XS
« Reply #125 on: November 30, 2017, 07:13:18 PM »
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.



  • Just arrived
  • *
  • Posts: 1
Re: Canon 1000d / Rebel XS
« Reply #126 on: February 15, 2018, 09:44:06 AM »
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?


  • Administrator
  • Hero Member
  • *****
  • Posts: 11210
  • 5D Mark Free
Re: Canon 1000d / Rebel XS
« Reply #127 on: February 15, 2018, 10:58:18 PM »

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


  • Just arrived
  • *
  • Posts: 1
Re: Canon 1000d / Rebel XS
« Reply #128 on: March 16, 2018, 07:19:26 AM »
Any news on the progress?


  • New to the forum
  • *
  • Posts: 38
Re: Canon 1000d / Rebel XS
« Reply #129 on: March 20, 2018, 08:13:50 PM »
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 :)


  • New to the forum
  • *
  • Posts: 47
Re: Canon 1000d / Rebel XS
« Reply #130 on: March 21, 2018, 04:43:41 PM »
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.


  • New to the forum
  • *
  • Posts: 47
Re: Canon 1000d / Rebel XS
« Reply #131 on: March 22, 2018, 12:18:16 PM »
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 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 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?


  • Administrator
  • Hero Member
  • *****
  • Posts: 11210
  • 5D Mark Free
Re: Canon 1000d / Rebel XS
« Reply #132 on: March 22, 2018, 02:29:22 PM »
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]
./ 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).


  • New to the forum
  • *
  • Posts: 47
Re: Canon 1000d / Rebel XS
« Reply #133 on: March 26, 2018, 03:36:47 PM »
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.


  • Administrator
  • Hero Member
  • *****
  • Posts: 11210
  • 5D Mark Free
Re: Canon 1000d / Rebel XS
« Reply #134 on: March 26, 2018, 05:01:01 PM »
LoadCalendarFromRTC: try FFCFDA6C

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

Need to do some digging to find the others.


  • New to the forum
  • *
  • Posts: 38
Re: Canon 1000d / Rebel XS
« Reply #135 on: March 27, 2018, 11:44:58 PM »
When I try to run QEMU, I get only a gray image.

Code: [Select]
./ 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


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.

4194304 ROM0.BIN
4194304 ROM1.BIN

Does anyone knows how to fix this?


  • Administrator
  • Hero Member
  • *****
  • Posts: 11210
  • 5D Mark Free
Re: Canon 1000d / Rebel XS
« Reply #136 on: March 28, 2018, 12:02:46 AM »
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);

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


  • New to the forum
  • *
  • Posts: 38
Re: Canon 1000d / Rebel XS
« Reply #137 on: March 28, 2018, 08:36:38 PM »
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.