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
source tree
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
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.
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.
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)
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:
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.
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.
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)
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).
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
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
= 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).
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?
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
YUV422_LV_BUFFER*
YUV422_HD_BUFFER*
Right?
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).
Alternative: http://magiclantern.wikia.com/wiki/Led_addresses
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?
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:
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)
>
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 :(
Possible reasons:
- 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).
Good.
Status: we can display a simple hello world message on screen using
dynamic fonts
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
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.
> 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 :)
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.
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
You can skip the last two (they are not important).
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?
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.
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
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 :)
It may be speed of light, but yesterday I didn't get a single keycode
right. I wonder what i was looking at :/
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
BUT after doing what I have said before, I cannot get the menu to open....
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
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;
}
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.
Damn canon engineers, always trying to reduce costs by removing buttons :(
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 :/
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
This kind of busy wait has very low impact on CPU, so it should be fine for now.
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?
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
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
Type this:
grep -nr lens_display_dirty ./
Can you send a screenshot with the fonts?
> 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 :)
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