1100D / Rebel T3

9,266 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
to ml-d...@googlegroups.com
Looks fine, you can plug them in stub.S. Lookup the missing stubs not
by name, but by the 550D address (most of them should be there, but
with some different name).

nanomad

unread,
Sep 10, 2011, 4:41:38 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 08:56, Alex <broscu...@gmail.com> wrote:
> Looks fine, you can plug them in stub.S. Lookup the missing stubs not
> by name, but by the 550D address (most of them should be there, but
> with some different name).
>
Done and done!
Here are some new stubs I identified using 550D address and
possible-code-matches.txt

NSTUB(0xFF1E8B9C, AcquireRecursiveLock) // (AJ_KernelDry_KerRLock.c)
(mean=7, stdev=9.8, num=17)
NSTUB(0xFF1E8CB0, ReleaseRecursiveLock) //
(AJ_KernelDry_KerRLock.c_p2) (mean=6.2, stdev=9.5, num=16)
NSTUB(0xFF1DA5F8, FIO_CleanupAfterFindNext_maybe) //
(AJ__switch_0x1A50_n_calls_fstOpenDir) (mean=25, stdev=10, num=11)
NSTUB(0xFF337C64, ReverseDisplay) // (Reverse) (mean=0.89, stdev=0, num=1)
NSTUB(0xFF31D3F4, dialog_redraw) // (dialog_draw) (mean=19, stdev=3.9, num=68)

I've disabled them for now since I'm not sure

The following stubs are still missing:
ChangeColorPalette
HideBottomInfoDisp_maybe

Alex

unread,
Sep 10, 2011, 4:44:10 AM9/10/11
to ml-d...@googlegroups.com
You can enable them without worrying.

You can skip the last two (they are not important).

nanomad

unread,
Sep 10, 2011, 5:09:50 AM9/10/11
to ml-d...@googlegroups.com
Thanks.
I've mapped almost all the DLG_*, but I want to make sure I got some
of them right...

DLG_Q_UNAVI -> When you press Q in picture mode
DLG_PICQ -> Photo resolution/type (e.g. RAW / L)
DLG_MOVIE_PRESS_LV_TO_RESUME -> How do I reach that?

Alex

unread,
Sep 10, 2011, 5:14:18 AM9/10/11
to ml-d...@googlegroups.com
That's it.

For the last two dialogs, go to movie mode, unscrew the lens and then
put it back. One message is when no lens is attached, other is when
the lens was attached back.

When you attach the lens back, Magic Lantern goes to movie mode by
itself. With Canon firmware you normally have to press LV.

nanomad

unread,
Sep 10, 2011, 5:27:51 AM9/10/11
to ml-d...@googlegroups.com
Got the last the one!

The other codes have been obtained by going to picture mode,
navigating the Q menu and entering the correct submenu (except for
DLG_MENU)

Done: Buttons & Dialogs
Next: Menu & Navigation

Alex

unread,
Sep 10, 2011, 5:34:45 AM9/10/11
to ml-d...@googlegroups.com
If they don't have all the same code as the Q menu itself, it's ok.
If they all have the same code as the Q menu, try enabling them from
the shortcut keys or from the menu.

nanomad

unread,
Sep 10, 2011, 5:49:56 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 11:34, Alex <broscu...@gmail.com> wrote:
> If they don't have all the same code as the Q menu itself, it's ok.

They are all different, so it should be OK

Now I'm here:
4) Enable the menu and navigation. For this, start user tasks, but
disable all modules with #include <disable-this-module.h> after all
other headers

I guess this means:
- go to src/boot-hack.c and enable my_big_init_task, disabling the
config_parse_file for extra safety
- replace platform/1100d.104/gui.c with the 600d. Make minor
adjustments here and there looking at the old 1100d one
- Hope that menu opens itself without killing someone :)

arm.indy

unread,
Sep 10, 2011, 6:21:49 AM9/10/11
to Magic Lantern firmware development
I prepared platform/1100d.104/gui.c with right message_queue and
counter offsets, so keep them.
the functions tables address and number should be also ok for the
1100d.

Indy

On Sep 10, 11:49 am, nanomad <condel...@gmail.com> wrote:

arm.indy

unread,
Sep 10, 2011, 6:26:27 AM9/10/11
to Magic Lantern firmware development
I would like to thank again Heavendew for testing first booting .fir
and autoexec.bin files, and also providing VRAM dumps, which then
allowed Nanomad and Alex to work an the unified version at speed of
light !

Indy

On Sep 10, 11:49 am, nanomad <condel...@gmail.com> wrote:

nanomad

unread,
Sep 10, 2011, 6:32:02 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 12:26, arm.indy <arm.i...@gmail.com> wrote:
> I would like to thank again Heavendew for testing first booting .fir
> and autoexec.bin files, and also providing VRAM dumps, which then
> allowed Nanomad and Alex to work an the unified version at speed of
> light !
>

It may be speed of light, but yesterday I didn't get a single keycode
right. I wonder what i was looking at :/

Alex

unread,
Sep 10, 2011, 7:20:43 AM9/10/11
to ml-d...@googlegroups.com
Surprise: ALL movie related structures seem **identical** with the 600D ones!
(which means you should be able to enable bitrate without any changes).

This seem the only difference (which is just the pointer to movie
recording structure).
#define MVR_992_STRUCT (*(void**)0x1DF4) // look in MVR_Initialize for
AllocateMemory call

And... yes, you've guessed it, run the code for 600D's 3x shortcut and
report the results.
Risk: ERR70 at startup in movie mode. Fix: clean camera settings, or
see http://groups.google.com/group/ml-devel/browse_thread/thread/cce670e003877214

nanomad

unread,
Sep 10, 2011, 7:25:02 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 13:20, Alex <broscu...@gmail.com> wrote:
> Surprise: ALL movie related structures seem **identical** with the 600D ones!
> (which means you should be able to enable bitrate without any changes).
>
> This seem the only difference (which is just the pointer to movie
> recording structure).
> #define MVR_992_STRUCT (*(void**)0x1DF4) // look in MVR_Initialize for
> AllocateMemory call
>
> And... yes, you've guessed it, run the code for 600D's 3x shortcut and
> report the results.
> Risk: ERR70 at startup in movie mode. Fix: clean camera settings, or
> see http://groups.google.com/group/ml-devel/browse_thread/thread/cce670e003877214
>
Nice, but before that I need to enable the menu.
The button codes are the same of the 600D too, (except for the missing
INFO button that is replaced the by DISP Press)

BUT after doing what I have said before, I cannot get the menu to open....

Alex

unread,
Sep 10, 2011, 7:32:26 AM9/10/11
to ml-d...@googlegroups.com
Put printf's in menu_task (make sure it's started), and take care of
open_canon_menu (comment it maybe).

To start the menu, you only need to call give_semaphore when you press
some button.

nanomad

unread,
Sep 10, 2011, 7:51:34 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 13:32, Alex <broscu...@gmail.com> wrote:
> Put printf's in menu_task (make sure it's started), and take care of
> open_canon_menu (comment it maybe).
>
> To start the menu, you only need to call give_semaphore when you press
> some button.

Ladies and gentleman we got a menu!
I had to check if TRASH was pressed in gui_main_task and in that case
I had to simply give the semaphore...
Since I can move in the ML menu, this means that gui_menu_shown() works.
So the trouble maker is GUISTATE_IDLE

nanomad

unread,
Sep 10, 2011, 8:02:32 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 13:51, nanomad <cond...@gmail.com> wrote:
> So the trouble maker is GUISTATE_IDLE
>
Of course it can't be a #DEFINE fault, so the real issue is gui_state
not getting properly intialized/updated
because of a wrong PROP_GUI_STATE in property.h ?
Or because of a missing PROP_HANDLER?

nanomad

unread,
Sep 10, 2011, 8:20:16 AM9/10/11
to ml-d...@googlegroups.com
More debugging.... gui state is getting correctly updated, but I don't
get any BUTTON TRASH event in IDLE state.
Could this be because on the 1100D the trash button is mapped to Av
+/- (of which I couldn't get a keycode) in IDLE state?

arm.indy

unread,
Sep 10, 2011, 9:07:38 AM9/10/11
to Magic Lantern firmware development

> Ladies and gentleman we got a menu!

excellent !

nanomad

unread,
Sep 10, 2011, 9:10:35 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 15:07, arm.indy <arm.i...@gmail.com> wrote:
>
>> Ladies and gentleman we got a menu!
>
> excellent !
>
And what's more, now we can open it...sort of...
Since trash is bound to AE COMP in IDLE state, we have to sacrifice
that function or find another button....
Moreover AE COMP triggers:
param 0x61 event 0xa
This happens twice (press/unpress, how lucky :/), so I had to write a
little antibumper to avoid the menu closing itself

nanomad

unread,
Sep 10, 2011, 9:17:44 AM9/10/11
to ml-d...@googlegroups.com
If anyone is interested:
Here's the button definition:
#define BGMT_AE_COMP (event->param == 0x61 && event->arg == 0xa)

And here's the antibump code:

if(gui_state == GUISTATE_IDLE) {
if(BGMT_AE_COMP) {
if(last_was_trash == 0) {
last_was_trash = 1;
} else {
last_was_trash = 0;
continue;
}
}

}
if( last_was_trash == 1 ) {
if (handle_buttons(event) == 0) // ML button/event handler
continue;
}

Alex

unread,
Sep 10, 2011, 9:29:05 AM9/10/11
to ml-d...@googlegroups.com
You may assign a short press for opening the menu and leave long press
for the normal Canon functionality.

I do this trick with flash button in movie mode (short press toggles
display presets, long press is a shift key).

Problem: you shouldn't add delays in gui_main_task (it will cause
crash sooner or later), so you need a way to read current timestamp
with pretty good resolution (to check if it was a long or a short
click). Look here:
http://groups.google.com/group/ml-devel/browse_thread/thread/f085043639991a7/

or try to use one "clock" task which runs at 10 Hz (i.e. while(1)
msleep(100)), like this:
- first press: assign 2 to some counter (or 3... see what works best)
- 10hz task: decrement counter (if nonzero)
- second press: if counter is nonzero, it was a short press => show the menu.

Other button... I guess all of them are being used in normal (idle) mode.

On 60D, the alternative shortcut for menu is MENU->UNLOCK.

nanomad

unread,
Sep 10, 2011, 9:45:58 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 15:29, Alex <broscu...@gmail.com> wrote:
> or try to use one "clock" task which runs at 10 Hz (i.e. while(1)
> msleep(100)), like this:
> - first press: assign 2 to some counter (or 3... see what works best)
> - 10hz task: decrement counter (if nonzero)
> - second press: if counter is nonzero, it was a short press => show the menu.
>
I guess that's the only viable solution, and also that I need to
engineer it a bit more since set and trash fire the same "strange"
event when in menu :/
So: use the "strange" button with timer when in IDLE
use the trash button when in menu

Damn canon engineers, always trying to reduce costs by removing buttons :(

nanomad

unread,
Sep 10, 2011, 10:25:23 AM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 15:45, nanomad <cond...@gmail.com> wrote:
> I guess that's the only viable solution, and also that I need to
> engineer it a bit more since set and trash fire the same "strange"
> event when in menu :/
> So: use the "strange" button with timer when in IDLE
> use the trash button when in menu
>
Nope, didn't work... events are still fired at random. Maybe I will
need to hijack the Q button

nanomad

unread,
Sep 10, 2011, 5:47:19 PM9/10/11
to ml-d...@googlegroups.com
On Sat, Sep 10, 2011 at 16:25, nanomad <cond...@gmail.com> wrote:
> Nope, didn't work... events are still fired at random. Maybe I will
> need to hijack the Q button
>

Or maybe not.
Thanks to Alex and Coutts work on the 550D I've managed to enable the
Tv/AE COMP button in ML for the 1100D

Protip: If the button is labeled Av +/- then you should grep for TV
and not AE :/

nanomad

unread,
Sep 10, 2011, 6:19:51 PM9/10/11
to ml-d...@googlegroups.com
And finally we have a reliable menu on ML.

Tv short press (short!) -> ML Menu
Tv long press -> predefined Canon function

The code for detecting short/long press uses busy wait (e.g. sleep())
instead of semaphores. This needs to be fixed, but I've got more
important stuff to do now

Alex

unread,
Sep 10, 2011, 7:13:46 PM9/10/11
to ml-d...@googlegroups.com
> The code for detecting short/long press uses busy wait (e.g. sleep())
> instead of semaphores. This needs to be fixed, but I've got more
> important stuff to do now

This kind of busy wait has very low impact on CPU, so it should be fine for now.

nanomad

unread,
Sep 10, 2011, 7:36:15 PM9/10/11
to ml-d...@googlegroups.com
On Sun, Sep 11, 2011 at 01:13, Alex <broscu...@gmail.com> wrote:
> This kind of busy wait has very low impact on CPU, so it should be fine for now.
>
Good to know

I've enabled lens.c
PROPS are getting parsed properly, but I've got no top/bottom bar in LV.
I've traced the issue back to BMP_LOCK( update_lens_display(); )
Since BMP_LOCK uses Acquire/Release Recursive Lock this means that the
stub.S is pointing the function to the wrong place

NSTUB(0xFF1E8B9C, AcquireRecursiveLock) // (AJ_KernelDry_KerRLock.c)
(mean=7, stdev=9.8, num=17)
NSTUB(0xFF1E8CB0, ReleaseRecursiveLock) //
(AJ_KernelDry_KerRLock.c_p2) (mean=6.2, stdev=9.5, num=16)

Does this make sense?

Andrew Coutts

unread,
Sep 10, 2011, 8:54:50 PM9/10/11
to Magic Lantern firmware development
Anything I can do?
what's the progress on stubs? I could sit down and start mapping those
out and making an IDC. using IDA i've gotten it to recognize 19,000
functions (compared to 9000 in the initial analysis), so it's off to a
pretty good start already.

Alex sent me an IDC but I couldn't load it for some reason. maybe he
just uses it in the console.

On Sep 9, 3:16 am, "arm.indy" <arm.indi...@gmail.com> wrote:
> 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
>
> On Sep 9, 8:14 am, Alex <broscutama...@gmail.com> wrote:
>
>
>
>
>
>
>
> > 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).
>
> > On Fri, Sep 9, 2011 at 8:57 AM, nanomad <condel...@gmail.com> wrote:
> > > 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 11, 2011, 12:51:13 AM9/11/11
to ml-d...@googlegroups.com
> PROPS are getting parsed properly, but I've got no top/bottom bar in LV.
> I've traced the issue back to BMP_LOCK( update_lens_display(); )
> Since BMP_LOCK uses Acquire/Release Recursive Lock this means that the
> stub.S is pointing the function to the wrong place

You can disable BMP_LOCK (define it as {x;} in bmp.h and recompile
from scratch); its role is to get rid of some redraw bugs. It will
work without it too.. sort of. Or you can replace recursive lock stubs
with null stubs.

The other one, GMT_LOCK, syncs some non-threadsafe Canon calls with
the gui_main_task (under the hypothesis that Canon calls to those
functions only come from gui_main_task). Since we are programming an
undocumented system, more testing is needed to find out how these
things work (and since now ML can run 1-2 hours under stress test
before crashing... it's not that easy to debug).

It's quite possible that GMT_LOCK it's not even needed now (maybe only
for redraw; need to do more stress testing for this function).

I debug these two by blinking the LED, or with the definitions which
are now commented out in bmp.h.

What is the value of bmp_lock and gmt_lock variables? (as hex). The
two stubs should be OK.

> Anything I can do?
For example, you can check consts/stubs by hand. I didn't take a
thorough look, so there might be one or two wrong.

> Alex sent me an IDC but I couldn't load it for some reason. maybe he
> just uses it in the console.

You already know how to solve with find/replace :P

nanomad

unread,
Sep 11, 2011, 4:46:23 AM9/11/11
to ml-d...@googlegroups.com
On Sun, Sep 11, 2011 at 06:51, Alex <broscu...@gmail.com> wrote:
> You can disable BMP_LOCK (define it as {x;} in bmp.h and recompile
> from scratch); its role is to get rid of some redraw bugs. It will
> work without it too.. sort of. Or you can replace recursive lock stubs
> with null stubs.
>
It wasn't BMP_LOCK fault *probably*
It looks like that the lens_display dirty bit is not getting updated
properly, or something like that.
menu_set_dirty is being called but as a result lens_display_dirty is
always 0 (and not 1 as I expected).


On a side node the FONT_SMALL and FONT_MEDIUM are really small, almost
unreadble since they look like they are missing some "lines".
If you do not understand what I mean I could upload a screenshot probably

Alex

unread,
Sep 11, 2011, 4:51:51 AM9/11/11
to ml-d...@googlegroups.com
lens_display_dirty: that's to limit the number of display updates (and
reduce flicker). It's updated from one of the liveview tasks.

Type this:
grep -nr lens_display_dirty ./

Can you send a screenshot with the fonts?

nanomad

unread,
Sep 11, 2011, 5:10:36 AM9/11/11
to ml-d...@googlegroups.com
On Sun, Sep 11, 2011 at 10:51, Alex <broscu...@gmail.com> wrote:
> lens_display_dirty: that's to limit the number of display updates (and
> reduce flicker). It's updated from one of the liveview tasks.
>
> Type this:
> grep -nr lens_display_dirty ./
>
It's in zebra high FPS task, and since zebra is disabled for now it makes sense.
I'm enabling zebra now. Let's hope for the best

> Can you send a screenshot with the fonts?
>

I took a VRAM dump with the debug menu and the picture showed up as a
720x480. Everything looks fine here
The 1100D has 230k dots 2,7 inch lcd

Also: my battery is dead, time to charge it :)

VRAM5.BMP

nanomad

unread,
Sep 11, 2011, 5:13:53 AM9/11/11
to ml-d...@googlegroups.com
On Sun, Sep 11, 2011 at 11:10, nanomad <cond...@gmail.com> wrote:
> I took a VRAM dump with the debug menu and the picture showed up as a
> 720x480. Everything looks fine here
> The 1100D has 230k dots 2,7 inch lcd
>
Which means 320x240x3 ... quite a bit smaller

Alex

unread,
Sep 11, 2011, 5:17:11 AM9/11/11
to ml-d...@googlegroups.com
> The 1100D has 230k dots 2,7 inch lcd
> Which means 320x240x3 ... quite a bit smaller
Boom :)

This reminds me of CHDK, where I could barely read the fonts for the
same reason.

For zebra, expect a vertical squish (easy to hack, harder to make a
portable fix). All cameras so far had the LV image buffer at 720x480;
the 1100D is the first one with 720x240 :P

It is loading more messages.
0 new messages