1100D / Rebel T3

9180 views
Skip to first unread message

arm.indy

unread,
Jul 26, 2011, 4:44:58 PM7/26/11
to Magic Lantern firmware development
If you're ok with helping with the 1100D, please let me know.
I would like to check code execution on it.

Indy

nanomad

unread,
Jul 26, 2011, 5:15:49 PM7/26/11
to ml-d...@googlegroups.com

Here I am :)

arm.indy

unread,
Aug 9, 2011, 2:50:54 PM8/9/11
to Magic Lantern firmware development
Hi!

anyone interested in a 2mn experiment on the 1100d / Rebel T3 ?

Indy

On 26 juil, 23:15, nanomad <condel...@gmail.com> wrote:

arm.indy

unread,
Aug 10, 2011, 2:57:22 PM8/10/11
to Magic Lantern firmware development
Hi,

I need someone with this camera to start ML dev on this camera.

Indy

arm.indy

unread,
Aug 14, 2011, 5:26:37 AM8/14/11
to Magic Lantern firmware development
Hi,

We just started working on porting ML on 1100D / Rebel T3 for firmware
1.0.4

Thanks to the contributor for his help!

Indy (no update and no camera in hands this time ;-)


201c 1.0.4
2024 K288
..
559480 DRYOS version 2.3, release #0047

arm.indy

unread,
Aug 14, 2011, 7:36:03 AM8/14/11
to Magic Lantern firmware development
For more information on the porting process see this new page
http://magiclantern.wikia.com/wiki/PortingML

Indy

nanomad

unread,
Aug 22, 2011, 12:17:51 PM8/22/11
to ml-d...@googlegroups.com

I'll get my camera back on the 26th of this month
Do not hesitate to contact  me if you need something tested :)

Jake

unread,
Aug 23, 2011, 10:48:05 AM8/23/11
to Magic Lantern firmware development
I have the camera and willing to test as long as nothing bad will
happen to it. im still paying it off for school and ive been waiting
for the FW to come out for it.
Message has been deleted

heavendew

unread,
Aug 27, 2011, 12:22:41 PM8/27/11
to ml-d...@googlegroups.com
I bought it few months back, sure i will try it

ty Indy

rolo

unread,
Sep 4, 2011, 9:28:41 AM9/4/11
to Magic Lantern firmware development
I have a t3 and i would be more then happy to help test

On Jul 26, 4:44 pm, "arm.indy" <arm.indi...@gmail.com> wrote:

arm.indy

unread,
Sep 5, 2011, 4:50:28 PM9/5/11
to Magic Lantern firmware development
please see .fir file sent here:
http://chdk.setepontos.com/index.php?topic=6682.msg72810#msg72810

incompatible with a eye-fi card !!!

Indy

arm.indy

unread,
Sep 6, 2011, 3:20:02 PM9/6/11
to Magic Lantern firmware development
Hi,

You can now find required files to start 1100D porting:
https://bitbucket.org/hudson/magic-lantern/changeset/c5c1c02bdfba

1. use provided magiclantern.fir to backup your memory and enable the
bootflag.
2. then compile source files to produce the autoexec.bin for your
tests.

See debug.c and dump_ram() on how to backup vram to find the VRAM
addresses.

Again, this is NOT a port of magic lantern for the 1100d, just a
minimal version to allow porting.

Next required step is having a developer for the 1100D / Rebel T3, I'm
sure there will be one, even if he/she not recognize himself/herself
yet...

I do not own this camera.

Indy

PS: sorry Alex, I used a 'dissident' ML version as a basis, because it
was easier for me.


On 4 sep, 15:28, rolo <rolando1...@gmail.com> wrote:

nanomad

unread,
Sep 8, 2011, 11:47:57 AM9/8/11
to ml-d...@googlegroups.com
Hi,
Since I do own a 1100D and know a bit of C, I would like to help if
possible, but I'm having issues compiling the 1100D files.

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

Alex

unread,
Sep 8, 2011, 11:51:32 AM9/8/11
to ml-d...@googlegroups.com
Try copying font files (font-*.c) from /src, and remove font rules
from Makefile.

You don't need the FIR, you can comment that rule too.

> --
> http://magiclantern.wikia.com/
>
> 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

nanomad

unread,
Sep 8, 2011, 11:58:36 AM9/8/11
to ml-d...@googlegroups.com
Looks like font-huge.c is missing.
And firmware won't compile without this (e.g. platform/1100D.104/bmp.c:225)

Alex

unread,
Sep 8, 2011, 12:01:51 PM9/8/11
to ml-d...@googlegroups.com
Font-huge? Remove it asap, or upgrade to a non-prehistorik version :)

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

nanomad

unread,
Sep 8, 2011, 12:12:10 PM9/8/11
to ml-d...@googlegroups.com

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

Alex

unread,
Sep 8, 2011, 12:21:54 PM9/8/11
to ml-d...@googlegroups.com
FONT_HUGE is the primary reason for weird crashes,
and I've removed it in late 2010. That version was full of bugs (and
that's why I wouldn't start porting from it).

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.
https://bitbucket.org/hudson/magic-lantern/changeset/4ea0e9dbe416

Look here for code for getting button codes:
https://bitbucket.org/up4/magic-lantern-for-600d-t3i/changesets

50D port starts here (it has gui_main_task in the old style):
https://bitbucket.org/hudson/magic-lantern/changesets/d4ddec8e33b7

Look for changesets having 600D or 50D in the name.

nanomad

unread,
Sep 8, 2011, 12:56:14 PM9/8/11
to ml-d...@googlegroups.com

Thanks!
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)

Alex

unread,
Sep 8, 2011, 1:06:51 PM9/8/11
to ml-d...@googlegroups.com
That's how I'd do it.

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.

nanomad

unread,
Sep 8, 2011, 6:32:04 PM9/8/11
to ml-d...@googlegroups.com
Thanks for the information!

I've branched the unified ML tree here:
https://bitbucket.org/nanomad/magic-lantern-for-1100d

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.

missing.txt

Alex

unread,
Sep 9, 2011, 12:50:01 AM9/9/11
to ml-d...@googlegroups.com
Apply this patch so it will compile at least. A few missing stubs are
important, though; you may add bmp_printf statements to them to see
when they are called.

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.
http://chdk.setepontos.com/index.php?topic=6729.msg71601#msg71601

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.

1100D.patch

nanomad

unread,
Sep 9, 2011, 1:57:26 AM9/9/11
to ml-d...@googlegroups.com

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)

Alex

unread,
Sep 9, 2011, 2:14:08 AM9/9/11
to ml-d...@googlegroups.com
Magic Lantern writes to the image buffers (so those should be correct
before enabling certain tasks).

These are:
- 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
HD buffers.

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

arm.indy

unread,
Sep 9, 2011, 3:16:52 AM9/9/11
to Magic Lantern firmware development, Arun Jose
Hi,

Sorry for the confusion of using an old version, but my goal was to
produce a minimal running code on the 1100D that:
- enable the bootflag
- create ML tasks
- dump RAM / VRAM buffer

and current ML version was too complex for me in the reduced amount of
time I have.
I can not follow Alex coding rythm...

I've got VRAM dumps (1.bin and 4.bin) from a contributor, using Alex
code, but no time to analyse them yet.


Neanderthal Indy

nanomad

unread,
Sep 9, 2011, 3:45:35 AM9/9/11
to ml-d...@googlegroups.com
Don't worry about the old version, actually porting your stuff helped me a lot.

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)

Nanomad

nanomad

unread,
Sep 9, 2011, 4:50:48 AM9/9/11
to ml-d...@googlegroups.com
I've just pushed a revision which compiles fine and shouldn't do
strange things with the camera *probably*

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

Alex

unread,
Sep 9, 2011, 5:05:47 AM9/9/11
to ml-d...@googlegroups.com
Since you've disabled prop_request_change, cfn.c should be fine. In
50D I've commented out the body of all these functions.

In boot-hack.c, for the first startup also comment task_dispatch_hook
= my_task_dispatch_hook.

First my_init_task can be as simple as this:

void
my_init_task(void)
{
// Call their init task
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).

nanomad

unread,
Sep 9, 2011, 5:41:24 AM9/9/11
to ml-d...@googlegroups.com
On Fri, Sep 9, 2011 at 11:05, Alex <broscu...@gmail.com> wrote:
> Since you've disabled prop_request_change, cfn.c should be fine. In
> 50D I've commented out the body of all these functions.
>
> In boot-hack.c, for the first startup also comment task_dispatch_hook
> = my_task_dispatch_hook.
>

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:
>
> void
> my_init_task(void)
> {
>        // Call their init task
>        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?

Message has been deleted
Message has been deleted

arm.indy

unread,
Sep 9, 2011, 6:20:43 AM9/9/11
to Magic Lantern firmware development
sdcard drive led (1100d 104):

ROM:FF1D9284 FIO_CreateFile
ROM:FF1D92D4 BL sub_FF347800

led_on
ROM:FF34781C LDRNE R0, =0xC0220134
ROM:FF347820 LDRNE R1, [R0]
ROM:FF347824 ORRNE R1, R1, #2
ROM:FF347828 STRNE R1, [R0]


ROM:FF1D9628 FIO_CloseFile
ROM:FF1D96AC BL sub_FF347830

led_off
ROM:FF347850 LDR R0, =0xC0220134
ROM:FF347854 LDR R1, [R0]
ROM:FF347858 BIC R1, R1, #2
ROM:FF34785C STR R1, [R0]

See http://magiclantern.wikia.com/wiki/PortingML page as a start to
describe the porting process.

Indy,

On Sep 9, 11:41 am, nanomad <condel...@gmail.com> wrote:

Alex

unread,
Sep 9, 2011, 9:18:03 AM9/9/11
to ml-d...@googlegroups.com
Got a screenshot.

Can you run the same dump code (for saving 4.bin) in LiveView? (with a
clear image if possible). Dump it twice if possible (4a and 4b) in the
same session (duplicate the dump_big_seg line).

0x40f77008.png

heavendew

unread,
Sep 9, 2011, 9:38:04 AM9/9/11
to Magic Lantern firmware development
Hi Alex

I ran the same dump code twice (normal mode & liveview mode) but i got
the same file size
when we start the camera, dumping process starts immediately! i have
to press liveview button after camera starts

On Sep 9, 6:18 pm, Alex <broscutama...@gmail.com> wrote:
> Got a screenshot.
>
> Can you run the same dump code (for saving 4.bin) in LiveView? (with a
> clear image if possible). Dump it twice if possible (4a and 4b) in the
> same session (duplicate the dump_big_seg line).
>
>
>
>
>
>
>
> On Fri, Sep 9, 2011 at 1:20 PM, arm.indy <arm.indi...@gmail.com> wrote:
> > sdcard drive led (1100d 104):
>
> > ROM:FF1D9284 FIO_CreateFile
> > ROM:FF1D92D4                 BL      sub_FF347800
>
> > led_on
> > ROM:FF34781C                 LDRNE   R0, =0xC0220134
> > ROM:FF347820                 LDRNE   R1, [R0]
> > ROM:FF347824                 ORRNE   R1, R1, #2
> > ROM:FF347828                 STRNE   R1, [R0]
>
> > ROM:FF1D9628 FIO_CloseFile
> > ROM:FF1D96AC                 BL      sub_FF347830
>
> > led_off
> > ROM:FF347850                 LDR     R0, =0xC0220134
> > ROM:FF347854                 LDR     R1, [R0]
> > ROM:FF347858                 BIC     R1, R1, #2
> > ROM:FF34785C                 STR     R1, [R0]
>
> > Seehttp://magiclantern.wikia.com/wiki/PortingMLpage as a start to
>  0x40f77008.png
> 10KViewDownload

Alex

unread,
Sep 9, 2011, 9:39:35 AM9/9/11
to ml-d...@googlegroups.com
Yes, you always get the same file size, but not the same file content.
I need this to plot the difference between them (but in LiveView).

Put some msleep of a few seconds before running the dump code.

nanomad

unread,
Sep 9, 2011, 9:56:04 AM9/9/11
to ml-d...@googlegroups.com
As far as I understand the dumper is the ML firmware Indy uploaded on
mercurial inside the platform/1100d.104 folder and which does not
compile as it is.

I've attached a patch (untested!) which allows the firmware to be
built from the current ML repo (unified branch).

1100d-dumper.patch

nanomad

unread,
Sep 9, 2011, 10:05:27 AM9/9/11
to ml-d...@googlegroups.com
Here's a patch that should enable the dumper (apply it after the previous one).
It waits 5 seconds, then dumps 1.bin and 4a.bin
Waits another second and finally dumps 4b.bin

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

dumper.diff

Alex

unread,
Sep 9, 2011, 11:38:10 AM9/9/11
to ml-d...@googlegroups.com
Image buffers found :)

Thanks to Heavendew for the dumps.

HD - 0x468cb600_0x4e8cb600.png
LV - 0x41ae8e50_412c8e50_416d8e50.png

nanomad

unread,
Sep 9, 2011, 11:53:02 AM9/9/11
to ml-d...@googlegroups.com

Great news. This should map to
YUV422_LV_BUFFER*
YUV422_HD_BUFFER*
Right?
I'll update my branch ASAP

Alex

unread,
Sep 9, 2011, 12:00:57 PM9/9/11
to ml-d...@googlegroups.com
That's right. Also add these values to the DMA buffers (without the
pointers). It won't work like it should (e.g. don't expect Magic
Zoom), but most basic things will work with that.

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.

nanomad

unread,
Sep 9, 2011, 1:51:39 PM9/9/11
to ml-d...@googlegroups.com
I've just arrived at home.
magiclantern.fir worked flawlessly.
On the card now I have:

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

Alex

unread,
Sep 9, 2011, 1:58:35 PM9/9/11
to ml-d...@googlegroups.com
I have them from Heavendew.

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.

arm.indy

unread,
Sep 9, 2011, 2:44:50 PM9/9/11
to Magic Lantern firmware development
the fir and autoexec.bin I provided already do that ;-)
but now it does it the unified way !

Indy

arm.indy

unread,
Sep 9, 2011, 3:06:12 PM9/9/11
to Magic Lantern firmware development
> I'm rebooting into linux now so that I can go on with the development :)
create a virtual machine and use vmplayer, it's free !

nanomad

unread,
Sep 9, 2011, 3:30:29 PM9/9/11
to ml-d...@googlegroups.com
On Fri, Sep 9, 2011 at 21:06, arm.indy <arm.i...@gmail.com> wrote:
>> I'm rebooting into linux now so that I can go on with the development :)
> create a virtual machine and use vmplayer, it's free !
>
Usually it's the other way around (virtualbox runs windows), but on
this "backup" machine (1.4 Ghz P4, 512Mb RAM) it's a miracle that it
still boots into a recent linux distro


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?

Alex

unread,
Sep 9, 2011, 3:50:48 PM9/9/11
to ml-d...@googlegroups.com
> NSTUB( 0xFF34781C, AJ_guess_LED_ON )
> NSTUB( 0xFF347850, AJ_guess_LED_OFF )

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

Alternative: http://magiclantern.wikia.com/wiki/Led_addresses

nanomad

unread,
Sep 9, 2011, 4:07:07 PM9/9/11
to ml-d...@googlegroups.com
On Fri, Sep 9, 2011 at 21:50, Alex <broscu...@gmail.com> wrote:
>> NSTUB( 0xFF34781C, AJ_guess_LED_ON )
>> NSTUB( 0xFF347850, AJ_guess_LED_OFF )
>
> 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).
>
I see what I did there :)
Time to dig out the ARM assembly book...

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

msleep(5000)
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?

nanomad

unread,
Sep 9, 2011, 4:10:47 PM9/9/11
to ml-d...@googlegroups.com
Update: The camera also boots without an autoexec.bin (AFAIK it should hang)

Alex

unread,
Sep 9, 2011, 4:11:54 PM9/9/11
to ml-d...@googlegroups.com
Well... bfnt only works on 550D for now. Use bmp_printf instead (copy
the FONTS.DAT on the card too).

Or try to blink the LED with card_led_blink.

arm.indy

unread,
Sep 9, 2011, 4:16:45 PM9/9/11
to Magic Lantern firmware development
my version of magiclantern.fir does not make the card bootable, and I
think it is dangerous for beginners (which enable bootflag) if they do
not also put a good autoexec.bin on their card

Again on the wiki
http://magiclantern.wikia.com/wiki/ARM

this book is also very good
http://www.amazon.com/Art-Assembly-Language-Randall-Hyde/dp/1593272073

ARM is far easier to understand than x86 for example.

Indy

On Sep 9, 10:07 pm, nanomad <condel...@gmail.com> wrote:

Alex

unread,
Sep 9, 2011, 4:18:11 PM9/9/11
to ml-d...@googlegroups.com
If the FIR ran (and hopefully enabled bootflag), you also have to make
the card bootable.

Since you are under Linux now, use make_bootable.sh.

Look in old 550D install method:
http://magiclantern.wikia.com/index.php?title=550d_install&redirect=no
(edit the page to see it)
and http://magiclantern.wikia.com/wiki/Bootdisk

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

nanomad

unread,
Sep 9, 2011, 4:18:45 PM9/9/11
to ml-d...@googlegroups.com
Thanks for the information!

Next step: get the damn card reader to work

nanomad

unread,
Sep 9, 2011, 4:22:14 PM9/9/11
to ml-d...@googlegroups.com
On Fri, Sep 9, 2011 at 22:18, Alex <broscu...@gmail.com> wrote:
> Since you are under Linux now, use make_bootable.sh.

Actually, the only PC that works well with sd card reader is the one
that can't run Linux :(

arm.indy

unread,
Sep 9, 2011, 4:31:37 PM9/9/11
to Magic Lantern firmware development
On Sep 9, 10:18 pm, Alex <broscutama...@gmail.com> wrote:
> Indy: the unified installer refuses to enable bootflag if autoexec.bin
> is not there.

oh yes, I forgot this very smart check.

nanomad

unread,
Sep 9, 2011, 4:38:27 PM9/9/11
to ml-d...@googlegroups.com
Update:
Made card bootable and garbled text (not readable) appeared on the
screen. Time to start debugging

Alex

unread,
Sep 9, 2011, 4:45:44 PM9/9/11
to ml-d...@googlegroups.com
Copy the fonts file and stop rushing :D

nanomad

unread,
Sep 9, 2011, 4:54:17 PM9/9/11
to ml-d...@googlegroups.com
I copied the FONTS.DAT both from the src folder and the latest stable
release (useless since they both have the same md5 but I discovered
that later)

nanomad

unread,
Sep 9, 2011, 5:11:52 PM9/9/11
to ml-d...@googlegroups.com
Just to make sure it wasn't my camera acting weird I compiled a
streamlined patched version of indy's dumper and it worked fine (I
could read everything on the screen)

Alex

unread,
Sep 9, 2011, 5:17:05 PM9/9/11
to ml-d...@googlegroups.com
Then define CONFIG_STATIC_FONTS and include the static fonts
(font-large, font-small, font-med) instead of font-dyn.

Possible reasons:
- card drive may be A: instead of B: (or maybe C: )
- FIO stubs incorrect (double-check them)

Alex

unread,
Sep 9, 2011, 5:28:25 PM9/9/11
to ml-d...@googlegroups.com
Dynamic fonts will be available after you call init_fonts (either via
call_init_funcs, or simply call them directly).

All FIO and memory stubs are correct (I've double-checked them now).

nanomad

unread,
Sep 9, 2011, 6:14:25 PM9/9/11
to ml-d...@googlegroups.com
On Fri, Sep 9, 2011 at 23:28, Alex <broscu...@gmail.com> wrote:
> Dynamic fonts will be available after you call init_fonts (either via
> call_init_funcs, or simply call them directly).
>
Yes, I discovered that after reading your previus mail with the
porting "suggestions"

> All FIO and memory stubs are correct (I've double-checked them now).

Good.

Status: we can display a simple hello world message on screen using
dynamic fonts
Next: button codes

Alex

unread,
Sep 9, 2011, 6:37:18 PM9/9/11
to ml-d...@googlegroups.com
Perfect :)

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
ptpNotifyOlcInfoChanged

#define FOCUS_CONFIRMATION (*(int*)0x41C8) // see "focusinfo" and
Wiki:Struct_Guessing
#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.

nanomad

unread,
Sep 9, 2011, 6:52:04 PM9/9/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 00:37, Alex <broscu...@gmail.com> wrote:
> Perfect :)
>
> After button codes we'll have the menu.
>
Good news: of all the buttons I tested (not every button, but close),
the codes were the same of those on the 600D.
To check the remaining ones I'll have to slow down button handling a
bit (msleep to the rescue!)

> 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
> ptpNotifyOlcInfoChanged
>
> #define FOCUS_CONFIRMATION (*(int*)0x41C8) // see "focusinfo" and
> Wiki:Struct_Guessing
> #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
firmware, right?

> SENSOR_RES_X / Y : take a RAW image and put the resolution there.
>

Will do

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

Alex

unread,
Sep 9, 2011, 6:56:44 PM9/9/11
to ml-d...@googlegroups.com
:) only 550D and 500D have sensors afaik. 60D doesn't.

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.

nanomad

unread,
Sep 9, 2011, 7:42:35 PM9/9/11
to ml-d...@googlegroups.com
I've pushed the last before-bed revision of the fork.
Beside button-spying code, the interesting stuff is located in
platform/1100d.104/misc.c
Here I've labeled the stubs identified by Alex with their
"probability". They should be reviewed by someone who has a better
understanding of ARM than me.
Unfortunately some stubs are still missing, maybe we can obtain them
from the 600D fw?

Alex

unread,
Sep 10, 2011, 2:56:48 AM9/10/11