Here I am :)
I'll get my camera back on the 26th of this month
Do not hesitate to contact me if you need something tested :)
Here's what I've done
- Cloned the ML "unified" branch from bitbucket
- Installed the GNU ARM Toolchain using the summon-arm script (GCC 4.6.0)
- Edited ML Makefile.inc to point to the correct toolchain (~/sat)
- Successfully compiled (aka make all) the standard ML firmare
- Entered the platform/1100D.104 folder
- Edited the Makefile to point to the correct toolchain and GCC version
- Run make
Got this error:
make: *** No rule to make target `../../../dumper/1100d_104_fake.fir',
needed by `magiclantern.fir'. Stop.
- Run make autoexec.bin (which made more sense after reading your mail)
Got this error:
make: *** No rule to make target `font-huge.in', needed by `font-huge.c'. Stop.
To me it looks like a bunch of font-related files are missing from the
You don't need the FIR, you can comment that rule too.
> To post to this group, send email to ml-d...@googlegroups.com
> To unsubscribe from this group, send email to ml-devel+u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/ml-devel?hl=en
On Thu, Sep 8, 2011 at 6:58 PM, nanomad <cond...@gmail.com> wrote:
> Looks like font-huge.c is missing.
> And firmware won't compile without this (e.g. platform/1100D.104/bmp.c:225)
And how would I do that?
I've got the latest revision from HG.
I guess I'll have to patch/backport bmp.c and the other nasty files
There are many good starting points for a port, like 60D installer,
600D installer, 600D initial port... even 50D port.
For someone who is not familiar with this code, it may be difficult.
Look in my previous e-mail (aug27) for a howto. You will have to get
constants and stubs from Indy's version. If it won't work, I'll take a
look at it these days.
I believe the best starting point is the 600D port, since these
cameras are from the same generation.
Look here for code for getting button codes:
50D port starts here (it has gui_main_task in the old style):
Look for changesets having 600D or 50D in the name.
Just to recap, you are suggesting this procedure:
Branch the latest Unified ML source
Throw "away" the current 1100 platform (keeping the .fir and some other stuff)
Take the 600D platform as a base for the new one
Replace stubs and consts with Indy version (mail of the 27th)
Start "following " your tutorial (mail of the 27th)
There are many dependencies between modules, but if you include
"disable-this-module.h", it will kill all the tasks and prop_handlers
without touching the dependencies.
A quick guide to modules (those will need to be disabled, and then
enabled one by one):
audio.c -> obvious (if the chip is like 600D, keep only audio meters)
zebra.c -> LiveV menu
shoot.c -> Shoot and Expo menus
movtweaks.c and bitrate.c -> Movie menu
tweaks.c -> Tweak menu
debug.c -> Debug menu
lens.c -> lots of core functions about photo settings; also movie
logging, top bar, bottom bar...
focus.c -> rack focus, follow focus...
Many functions will work without any button handler (so you can start
only with the handler which enables menus). Shortcut keys are tricky,
don't jump into them.
I've branched the unified ML tree here:
The code doesn't compile yet because of missing function stubs. Do you
have any suggestion on how to obtain those?
For the record, I've attached the missing functions
PS: I've yet to flash my camera with the .fir.
Basically I've replaced them with empty functions, and adapted Indy's
gui.c (simplfied a bit).
Don't run it like it is now; disable things from boot-hack.c and the
modules first. But I think you should be able to boot and print hello
world. That's the first big step. Next, uncomment TASK_OVERRIDE in
gui.c to show button events.
If you don't know something about a function (let's say
draw_ml_bottombar), search for it in all ML files.
Also disable the functions for moving around AF frame, and look for
prop_request_change calls with arg2 higher than 4; I expect these to
be different. These functions may write data into NVRAM or ROM, and
incorrect data may cause ERR70 at startup, even without ML.
You may even replace prop_request_change with a dummy stub to be on
the safe side (this way, ML won't be able to change any settings, but
it will be able to read them).
Before changing new properties, I check them first in read-only mode
(i.e. if correct values are displayed), I also check the length of the
data (second number in prop spy), I try to figure out valid values
(from Canon code or from prop spy) and after that, I try to change it.
Luckily, most properties are the same in all cameras (but not all).
That's it for now, keep us posted.
Thanks for the patch!
So far I've defined the 1100D as an early port so much of the boot-hack code should be disabled IIRC
I've also disabled most (all?) of the modules.
Regarding the prop_request _change function I'll probably dummy it in the beginning. Better safe than sorry :)
As soon as I get to the office I'll apply the patch, fix the above function and start fixing the constants file to avoid defining symbols twice.
One last question ...is it safe to zero out all the unknown constants? (Beside buttons and strings which should be harmless)
- magic zoom (writes to LV buffer) => make sure zebra works first
- playback image processing stuff (which you have to call from gui.c
first, and it only happens when you press buttons) => this writes to
So, instead of YUV422_HD_BUFFER_DMA_ADDR, you may put some known
buffer address (like YUV422_HD_BUFFER ) until we find the pointer.
Zero out CURRENT_DIALOG_MAYBE, LV_BOTTOM_BAR_DISPLAYED,
ISO_ADJUSTMENT_ACTIVE, SHOOTING_MODE (they may only cause stuff not
being drawn on screen). Others should be safe (I prefer to leave most
of them non-zero during porting, as quite a few may be common between
I've got a couple of quick questions for you
- How did you obtain the stubs?
- Which consts are from the 1100D itself? (I guess everything out of the #if 0)
I'm not quite sure I did the correct thing with cfn.c (I've just
replaced the return of get_mlu with a return 0)
If everything is right, the next step should be using bmp_printf() to
make the camera say something stupid.
As far as I understand, commenting stuff in boot-hack.c disabled ML
task creation but ML firmware is still being run.
I should put the printf in the my_init_task in boot-hack.c just after
the call to init_task()
In boot-hack.c, for the first startup also comment task_dispatch_hook
First my_init_task can be as simple as this:
// Call their init task
msleep(5000); // wait for the camera to start
print hello world
If it doesn't print, you can play with version string stuff, or we'll
have to find how to blink the LED.
To find the constants and stubs, we look in the firmware dump (usually
for strings or for similar context.. i.e. pattern matching in ASM
code). We compare it with the firmware dumps for other cameras
(especially 550D). There are automated tools which help with this task
(but they are not 100% accurate).
Thanks to CONFIG_EARLY_PORT this was already disabled
Whoever did this deservers a beer.
So, booting this firmware should start the canon one without almost
anything ML-related right?
How can I check if it worked? (I guess the answer is use printf)
btw I've tagged this revision 1100d-firstboot if anyone is willing to
experiment before I get home
> First my_init_task can be as simple as this:
> // Call their init task
> msleep(5000); // wait for the camera to start
> print hello world
> If it doesn't print, you can play with version string stuff, or we'll
> have to find how to blink the LED.
I'll try this as soon as I get home this evening. Let's hope for the best
> To find the constants and stubs, we look in the firmware dump (usually
> for strings or for similar context.. i.e. pattern matching in ASM
> code). We compare it with the firmware dumps for other cameras
> (especially 550D). There are automated tools which help with this task
> (but they are not 100% accurate).
I've looked at the wiki and I don't see a procedure for dumping the
firmware to the SD card.
Do the bins that indy obtained with the "reduced" ML also contain the
code portion of the firmware? Can I use that procedure to dump it?
Put some msleep of a few seconds before running the dump code.
I've attached a patch (untested!) which allows the firmware to be
built from the current ML repo (unified branch).
I would like ARM or Alex to check them first, since I'm not a real
expert with ML code and I'm still at my office without the camera
Great news. This should map to
I'll update my branch ASAP
You will need some vertical scaling for zebras.
To find the DMA pointers, you need to run Indy's stateobj code again
(in LiveView mode), or my memspy patch modified with the new values.
But that's already advanced stuff.
ROM0.BIN (9437184 B)
LOG000.LOG (70288 B)
F8000000.BIN (8388608 B)
FFFF0000.BIN (65535 B)
LOG001.LOG (49815 B)
Let me know if you still need any of those files.
I'm rebooting into linux now so that I can go on with the development :)
ROM0.bin is the firmware image (it contains ARM ASM code); you can
load it in IDA demo or in GPL tools found on ML and CHDK wiki.
Back to the topic, I was looking at the LED stubs in order to insert
what you discovered before:
NSTUB( 0xFF34781C, AJ_guess_LED_ON )
NSTUB( 0xFF347850, AJ_guess_LED_OFF )
Does it look good to you?
That's a good occasion to brush up your hex and ASM skills (these
numbers are exactly the same as in Indy's LED-related message).
But before I start digging into ARM deeper I would like to have a
confirmation that ML is booting fine on my camera.
- Run magiclantern.fir
- After writing the files to the SD and setting the boot flag, the
camera powered itself down
- Re-inserted battery
- Camera powered up without SD card
- Copied a simple autoexec.bin to the SD card (one that does nothing)
- Camera powered up fine
- Edited boot-hack.c and added the follwing code to my_init_task just
after the additional_version stuff
bfnt_puts("HELLO MAGIC LANTERN!", 50, 50, COLOR_WHITE, COLOR_BLACK);
- Re-uploaded the autoexec
- Camera powered fine
- No sign of the HELLO MAGIC .... stuff on the screen.
The question is: magiclantern.fir enables the BOOTFLAG but does it
make the card bootable?
Or try to blink the LED with card_led_blink.
Since you are under Linux now, use make_bootable.sh.
Look in old 550D install method:
(edit the page to see it)
The new installers do this automatically (but the unified installer
for 1100D is not available yet).
Indy: the unified installer refuses to enable bootflag if autoexec.bin
is not there.
On Fri, Sep 9, 2011 at 11:10 PM, nanomad <cond...@gmail.com> wrote:
> Update: The camera also boots without an autoexec.bin (AFAIK it should hang)
Next step: get the damn card reader to work
Actually, the only PC that works well with sd card reader is the one
that can't run Linux :(
- card drive may be A: instead of B: (or maybe C: )
- FIO stubs incorrect (double-check them)
All FIO and memory stubs are correct (I've double-checked them now).
> All FIO and memory stubs are correct (I've double-checked them now).
Status: we can display a simple hello world message on screen using
Next: button codes
After button codes we'll have the menu.
A few consts:
#define CURRENT_DIALOG_MAYBE (*(int*)0x3960) // GUIMode_maybe in Indy's IDC
(print its value in a loop, e.g. in debug_loop_task, to find DLG_* consts )
#define LV_BOTTOM_BAR_DISPLAYED (((*(int8_t*)0x5350) == 0xF) ||
((*(int8_t*)0xCBD4) != 0x17)) // dec CancelBottomInfoDispTimer
#define ISO_ADJUSTMENT_ACTIVE ((*(int*)0x5350) == 0xF) // dec
#define FOCUS_CONFIRMATION (*(int*)0x41C8) // see "focusinfo" and
#define FOCUS_CONFIRMATION_AF_PRESSED (*(int*)0x1b98) // used for Trap
Focus and Magic Off.
// To find it, go to MainCtrl task and take the number from the second
line minus 4.
SENSOR_RES_X / Y : take a RAW image and put the resolution there.
DISPLAY_SENSOR: does the 1100D have this? (does it turn off
automatically when you look through the viewfinder?)
There are strings in the firmware, but I can't see where is the sensor.
> A few consts:
> #define CURRENT_DIALOG_MAYBE (*(int*)0x3960) // GUIMode_maybe in Indy's IDC
> (print its value in a loop, e.g. in debug_loop_task, to find DLG_* consts )
Will do (I take the #define is correct)
> #define LV_BOTTOM_BAR_DISPLAYED (((*(int8_t*)0x5350) == 0xF) ||
> ((*(int8_t*)0xCBD4) != 0x17)) // dec CancelBottomInfoDispTimer
> #define ISO_ADJUSTMENT_ACTIVE ((*(int*)0x5350) == 0xF) // dec
> #define FOCUS_CONFIRMATION (*(int*)0x41C8) // see "focusinfo" and
> #define FOCUS_CONFIRMATION_AF_PRESSED (*(int*)0x1b98) // used for Trap
> Focus and Magic Off.
> // To find it, go to MainCtrl task and take the number from the second
> line minus 4.
I guess all those #define values are correct and extracted from the
> SENSOR_RES_X / Y : take a RAW image and put the resolution there.
> DISPLAY_SENSOR: does the 1100D have this? (does it turn off
> automatically when you look through the viewfinder?)
> There are strings in the firmware, but I can't see where is the sensor.
No sensor, it's a poor-man camera :)
All consts were extracted from firmware (from decompiling stuff) so I
expect them to work.
For menu: open_canon_menu() may create problems with new ports (it
needs GUI_Control and some DLG codes). Just to let you know.