Author Topic: Linux on your Canon DSLR? Why not?  (Read 170403 times)

thearczoro

  • New to the forum
  • *
  • Posts: 12
  • Eggless
Re: Linux on your Canon DSLR? Why not?
« Reply #75 on: April 06, 2015, 11:55:03 AM »
Is it possible to run custom OS for ARM like Arduino or Raspberry Pi? That used for drone controller.
Camera: Canon 500D
FW: 1.1.1
ML: Nightly (4 October 2017)

Walter Schulz

  • Contributor
  • Hero Member
  • *****
  • Posts: 7296
Re: Linux on your Canon DSLR? Why not?
« Reply #76 on: April 06, 2015, 12:00:03 PM »
Raspberry Pi's OSs are (mostly) customized Linux.
Other OS ported: RISC OS 5, Plan 9, FreeBSD, NetBSD ...

Therefore not sure what you are asking.
Photogs and videographers: Assist in proof reading upcoming in-camera help!. Your input is wanted and needed!

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12420
Re: Linux on your Canon DSLR? Why not?
« Reply #77 on: April 06, 2015, 12:33:01 PM »
@nikfreak: that's good, so 152f67a06a45 boots fine. Now, since there are few changesets, can you try them one by one?

If you need a xipImage, just use any of them. You are troubleshooting the display init routine after all, and this happens before jumping to the Linux kernel.

sooda

  • New to the forum
  • *
  • Posts: 11
Re: Linux on your Canon DSLR? Why not?
« Reply #78 on: April 06, 2015, 12:43:17 PM »
A compressed initrd is easy with a small change. The atag for the ramdisk needs to be the actual, uncompressed size. Otherwise I got a "RAMDISK: incomplete write ...". It can also be bigger - say, just set it to 16MB and be done with it until the error appears again and double the size if necessary. It's usually unmounted and the memory freed anyway when the actual rootfs would be mounted from the memory card. When I hardcoded its exact uncompressed size in the bootloader and bzip2'd the image then the userspace init loaded successfully (the config didn't have gzip support enabled - with it set, also a gzipped image works).

chmee

  • Contributor
  • Hero Member
  • *****
  • Posts: 1031
  • raw2cdng
Re: Linux on your Canon DSLR? Why not?
« Reply #79 on: April 06, 2015, 12:57:14 PM »
@thearczoro
Arduino code is mostly written in c and precompiled before sent to the arduino. so. there s no OS. an arduino just has a small init and then startadress to the assemblercode. more interesting (because widely known) are OSes like an android-derivate (linux-based as well) or Win/CE. But who will take his time to realize that? a small linux is a good choice - and coding modules can be (in future) as simple as for arduino. small ide, module-folder, done.

nikfreak

  • Developer
  • Hero Member
  • *****
  • Posts: 1170
Re: Linux on your Canon DSLR? Why not?
« Reply #80 on: April 06, 2015, 03:17:32 PM »
@nikfreak: that's good, so 152f67a06a45 boots fine. Now, since there are few changesets, can you try them one by one?

If you need a xipImage, just use any of them. You are troubleshooting the display init routine after all, and this happens before jumping to the Linux kernel.

ofc! will keep you informed.
70D.112 & 100D.101

illwieckz

  • New to the forum
  • *
  • Posts: 14
Re: Linux on your Canon DSLR? Why not?
« Reply #81 on: April 06, 2015, 06:34:57 PM »
Hi, do you think this hack will allows us to run the same software on EOS DSLR than in Axiom cameras from Apertus, allowing to mutualize code and to have a real functionnal (able to shot) linux-based firmware on EOS DSLR? Since a linux based firmware is currently developped at least for Axioms, is it possible to port it to EOS DSLR?  ???

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12420
Re: Linux on your Canon DSLR? Why not?
« Reply #82 on: April 06, 2015, 06:44:02 PM »
If we'll ever get as far as being able to read buttons and take a picture / record a video, the answer will be probably yes.

Right now, we are not there yet.

illwieckz

  • New to the forum
  • *
  • Posts: 14
Re: Linux on your Canon DSLR? Why not?
« Reply #83 on: April 06, 2015, 07:32:52 PM »
Ok, but at least, this is fun! (5DM3 here)


CITY-U1001

  • New to the forum
  • *
  • Posts: 46
  • 50D in future
Re: Linux on your Canon DSLR? Why not?
« Reply #84 on: April 06, 2015, 08:04:42 PM »
i want quake on my canon 50D ! :D
50D | EFS 18-55 | last build crop_rec-3744x1080_24fps_50D-eXperimental.4.57pm.2020May06.50D109.zip

delle54

  • New to the forum
  • *
  • Posts: 2
  • EOS 550D
Re: Linux on your Canon DSLR? Why not?
« Reply #85 on: April 06, 2015, 09:50:42 PM »
These news are exciting. I don't expect further results very soon and will patiently observe what's going on. I wish those who try to implement linux on canon cameras good luck.

Pressing the "shoot-button" does following in the modes:

- A-Dep: autofocus does something...
- Manual: the same...
- Av: half of the above...
- Tv: the same...
- P:  the same...
- CA: the same plus multiple flashes...
- Automatic: the same as CA...
- the following modes incl. movie do the same, some with or without multiple flashes.

timelapseHD

  • New to the forum
  • *
  • Posts: 22
  • Canon 1100D
Re: Linux on your Canon DSLR? Why not?
« Reply #86 on: April 06, 2015, 10:42:51 PM »
Test on 1100D with the build from the first post.
Canon 1100D

delle54

  • New to the forum
  • *
  • Posts: 2
  • EOS 550D
Re: Linux on your Canon DSLR? Why not?
« Reply #87 on: April 06, 2015, 10:47:09 PM »
"deleted"

kitor

  • Contributor
  • Member
  • *****
  • Posts: 161
Re: Linux on your Canon DSLR? Why not?
« Reply #88 on: April 06, 2015, 11:07:14 PM »
I *might* be able to help a little.
Long time ago (well, very long: http://pdasite.pl/kitor/maui_linux/, half of site is not working now) I was able to port Linux kernel to some unsupported PDA. The fact is that there existed one that was supported and similar hardware-wise, but it still it involved looking for gpios, etc.
I have half-dead 50d (err50, but it has bootflag enabled), also one burned motherboard (doesn't power on). I don't have right now access to hotair rework station, but I should have in two-three weeks - I'll clean this damaged board from all elements and try to at least partially recreate gpio map. Of course if that wasn't done before.
EOS R

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3155
Re: Linux on your Canon DSLR? Why not?
« Reply #89 on: April 07, 2015, 01:24:50 AM »
anyone can explain me how the kernel tries to start init?
according to http://lkml.iu.edu/hypermail/linux/kernel/0105.2/0910.html

the context switch to userspace code happens implicitely by patching the stored context on stack.
so when the syscall returns to userspace, it simply restores the new registers etc.

but in linux kernel's init/main.c it calls init via
run_init_process -> do_execve -> do_execveat_common -> exec_binprm -> search_binary_handler -> load_flat_binary (here current->mm gets modified)

we do not come from a syscall (SVC) there... now where would we expect the magic stuff to happen?
anyone? this is essential...
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

sooda

  • New to the forum
  • *
  • Posts: 11
Re: Linux on your Canon DSLR? Why not?
« Reply #90 on: April 07, 2015, 07:23:32 AM »
That lkml answer is not quite complete, as it only describes exec done from an already existing user process via the execve() syscall. In Linux, context switches happen often implicitly. There is an explicit timer that runs CONFIG_HZ times per second for that, but often the scheduler runs implicitly in e.g. mutex_lock(), and several other places too (grep for cond_resched(), or might_sleep()). Process creation just sets up the process and puts it in the scheduler's task list, where it is started "sometime later", AFAIK. Returning from syscalls is one of those implicit places, like the lkml answer says. After having handled an interrupt is another I guess.

If you put printk()s all over the place where kernel_init() is called and run_init_process() too, you'll see that it just returns. Track schedule() to see that init actually gets set up:

Code: [Select]
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2849,6 +2851,10 @@ asmlinkage __visible void __sched schedule(void)
        struct task_struct *tsk = current;
 
        sched_submit_work(tsk);
+       printk("schedule %d:%s @ %lx\n", tsk->pid, tsk->comm, instruction_pointer(current_pt_regs()));
        __schedule();
 }
 EXPORT_SYMBOL(schedule);

Result: continuous prints between init (its ip doesn't increment though :-/) and ksoftirqd. (not sure if ksoftirqd actually has something to do or not... and its ip appears zero since it doesn't have an user process - regs of a process get saved in the end of its stack; for kernel threads, that memory has other uses)



(the log contains some of my other debug prints too, but that's irrelevant)

I recommend a good book, as these things are not consistently described elsewhere unless you really dig through the whole code - Robert Love's Linux Kernel Development is a recent one. (edit: by consistent, I mean that you have to swim around the internets to find small bits of information at a time. That's probably necessary for some ARM specific stuff anyway, though.)

I'll discuss this at work - we've got many old Linux experts that are probably interested. Will keep you updated.

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3155
Re: Linux on your Canon DSLR? Why not?
« Reply #91 on: April 08, 2015, 12:02:00 AM »
@sooda:

wow, thanks for that clarification.
for linux, we are still at the beginning of a hard learning procedure.

i am happy about any helping hand, so yes, ask your colleagues :)
thanks!

edit:
as i successfully set up buildroot with a hand full of patches/configs, i have another cross compiler variant that i want to try to build the linux kernel.
maybe the arm-non-eabi- cross compiler doesnt work (EABI vs. ABI differences?)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

raiky

  • New to the forum
  • *
  • Posts: 7
Re: Linux on your Canon DSLR? Why not?
« Reply #92 on: April 09, 2015, 12:45:13 AM »
Hi Congrats for this good work guys!  ;)

I thought I can also play a little with my 6D to make it work

I'm able to compile the normal ML for 6D,  but dont know how to build this one :-[. Is there some short instructions on how to make this boot loader? I'm a bit lost, I just tried with "make 6D" again but it complains about xipImage or so :)  My dev env. is a magiclantern virtualbox I downloaded from this site.

Cheers. ;D
R.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12420
Re: Linux on your Canon DSLR? Why not?
« Reply #93 on: April 11, 2015, 03:31:51 PM »
Our Linux port now runs under QEMU as well :)



More info about QEMU: http://www.magiclantern.fm/forum/index.php?topic=2864
(I've tested it on 60D; other cameras may work or may not)

Albert

  • New to the forum
  • *
  • Posts: 7
Re: Linux on your Canon DSLR? Why not?
« Reply #94 on: April 11, 2015, 07:31:59 PM »
Has anyone read up on uClinux? Thats designed with MMU-less platforms in mind. Not sure how much it'd support ARM architecture exactly, as it is currently based on kernel 3.4, 2-3 years ago now.

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3155
Re: Linux on your Canon DSLR? Why not?
« Reply #95 on: April 11, 2015, 08:02:31 PM »
as linux kernel itself now contains the -nommu patches from uClinux, we already use that.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

sooda

  • New to the forum
  • *
  • Posts: 11
Re: Linux on your Canon DSLR? Why not?
« Reply #96 on: April 12, 2015, 11:25:33 AM »
I just pulled again and tried qemu with a 700D build. It booted up until the delay loop calibration, where it got stuck every time as it got no timer interrupts. I copied the eos_trigger_int() call also to the "interrupt enable?" branch in eos_handle_timers() and got the timer interrupts properly in Linux and the boot process continued properly. Edit: Whoops, i didn't notice the change in the linux patch. now it works without changes. Great - now that qemu runs linux, gdb can be used to debug the process starting issues.

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3155
Re: Linux on your Canon DSLR? Why not?
« Reply #97 on: April 12, 2015, 11:35:15 AM »
i have also some changes to qemu, so it emulates the real hardware better. (i hope ;) )
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3155
Re: Linux on your Canon DSLR? Why not?
« Reply #98 on: April 12, 2015, 11:49:45 AM »
btw, switched to zImage which is the "correct" way of booting linux.
but i have weird behavior due to random memory overwrites....
at one point i had the impression the kernel uses its own memory as memory that can be used for (k)malloc.
causing it to overwrite its own memories.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

sooda

  • New to the forum
  • *
  • Posts: 11
Re: Linux on your Canon DSLR? Why not?
« Reply #99 on: April 12, 2015, 12:26:11 PM »
Did you configure all the necessary things for the zImage way? The initial decompressor needs a separate memory area that is a normal CONFIG_whatever setting IIRC.

About the context switches: the actual switch happens in arch/arm/kernel/entry-common.S, around ret_to_user(), in a macro called restore_user_regs. I can see that the program counter goes properly into the user process (disassembly in gdb shows its asm source, and the address is the same that is printed in load_flat_binary()), but a single step at the first "mov r2, 0x39" does not appear to run that but instead gdb freezes, and a ^C breaks properly but shows the machine in a strange state, pc being 0xc, in __vectors_start+12 which contains a jump to vector_pabt, which means an abort exception, and lr contains just 0x10 (the jump never happens though - as if it would trigger another abort again). Looks like 0xc is a prefetch abort in arm. I wonder if the memory is not set up correctly or some cache flag goes wrong in the context switch mangling?