We, the Magic Lantern Team, are very proud to present you a new milestone in DSLR customization!LINUX ON CANON EOS CAMERAS!(edit: after playing a game, making it look like an April's fool, we can ensure:
this is not a fake!)
Starting from our recent discovery about display access from bootloader (http://www.magiclantern.fm/forum/index.php?topic=14732), we thought, hey, we could now have full control of the resources from this embedded computer. At this stage, we knew what kind of ARM processor we have (ARM 946E-S), how much RAM we have (256MB/512MB depending on the model), how to print things on the display (portable code), how to handle timers and interrupts, how to do low-level SD card access on select models (600D and 5D3), and had a rough idea where to start looking for button events.
So, why not trying to run a different operating system?
We took the latest Linux kernel (3.19) and did the first steps to port it. As we have nearly zero experience with kernel development, we didn't get too far, but we can present a proof of concept implementation that...
...boots the Linux kernel 3.19 on Canon EOS DSLR cameras!- it is portable, the same binary runs on all ML-enabled cameras (confirmed for 60D, 600D, 7D, 5D2 and 5D3)
- allocates all available RAM
- prints debug messages on the camera screen
- sets up timer interrupts for scheduling
- mounts a 8 MiB ext2fs initial ramdisk
- starts /bin/init from the initrd
- this init process is a selfcontained, libc-less hello world
- next step: build userspace binaries (GUI, etc)
Demo video:
Download: autoexec.bin (http://upload.g3gg0.de/pub_files/9deafc742bc7fe71cbf39a06f7b8b9fa/autoexec.bin)
Source code (WIP): https://bitbucket.org/hudson/magic-lantern/branch/linux-bootloader
We hope this proof of concept will encourage you to tinker more with your new embedded computer. Maybe you want to run Angry Birds on it, or maybe Gimp? :)
Enjoy!
This opens up so many possibilities. Just wow!
Definitely another pipe dream coming true for many!
I've just notice that I haven't had an properly account yet --
anyway ... just had to comment this great new, it's amazing! Thanks for share ;)
:D :D
1. April? :/
If this is as true as you seem to imply on Twitter, you sure chose a great day to announce it!
hahaha
yes ... inopportune day to announce
If it is real: how much do we know about the usb interface chip?
It would be great to get something like adb working to have an interactive shell.
Playing with expections: Boss level!
Awesome. Now we can run exiftool straight in the cam :P
It's quite easy to tell that this whole video is computer generated.
And if you read closely what is written on the SD card it says "April Fools".
If you are not exactly a Linux fan, you might want to try this: http://www.magiclantern.fm/forum/index.php?topic=14853
WOW! Congrulations! This is big!
Excelent notice
Hhhmm... That would be awesome. ;)
great. I can use facebook with my d600
April fool?
should i be honest?
Where is the fun in that?
we had enough fun seeing responses that were somewhere between "AMAZING!" and "haa, haa...."
so.. enjoy the demo. we had fun with creating it :)
you will be the first ones who boot linux on their DSLR.
and i hope there will be some more soon :)
we updated the first post, check it
Ok, I tried it on 7D and had Linux running and my first kernel panic on DSLR.
(http://picload.org/image/igirpaa/comp_img_5279.jpg)
see, you are one of the first people ever having a kernel panic on the 7D.
very few people can tell this :)
the kernel panic is due to my hackish "init" process, that only prints a "hello world", exiting back to kernel.
thats a good thing.
Yes, first person officially reporting 7D with kernel panic!
And 650D, too.
Not that much Endorphin released, though!
On second thought: This is pretty much "Alice's Adventures in Wonderland" opening the door after falling down the rabbit hole. I cannot imagine all the options ...
500D
(http://s21.postimg.org/ic292ny5z/500d.jpg)
EOS-M also seems to boot it.
Is there already a git/hg for kernel/initrd/userspace set up?
pranked by BSOD but this autoexec doesn't even power on 70D.
i just published the patch to linux-3.19 and the sample init. d2c975f (https://bitbucket.org/hudson/magic-lantern/commits/d2c975feed44e26cab9d59be6761a826e7f25583) 2bcf4b8 (https://bitbucket.org/hudson/magic-lantern/commits/2bcf4b86126acb3b3c8b7139be625e7f9f32523d)
but beware, its not simple to build it. it took me about 5 nights to get it that far.
fiddled a lot with uClibc, busybox etc but didnt get a clean build.
if there are some linux gurus out there: please help us!
It doesn't seem to play nice with my 6D - popped the card in and it was completely unresponsive with blank screens until I pulled the battery.
.. cool development though, and my camera is fine now that I've removed the linux autoexec.bin
@SenorClean: does the display test work for you on 6D?
http://www.magiclantern.fm/forum/index.php?topic=14732.0
So I don't mean to be a troll buuuuuuuuuttt....
With this, the canon DSLRs can be recoded from the ground up to do what we want?
DOES THIS MEAN PRORESES AND 4'S OF K?!?!?!?! :D :D :D
But seriously, does this mean smoother operation, and one thing which I am super wondering about, raw video via HDMI for recording, or use it to help supplement raw to CF? Like recording part of it on a CF card or SD card and then the other part of HDMI for max output?
And french fries (might be even easier to implement that).
Or maybe a Swiss cheese fondue ? ;)
@A1ex - yes, that one seems to work fine:
http://i.imgur.com/FNk8bTS.jpg
And you get no display at all with the Linux binary? Not even backlight, or just no text?
No backlight or text - all I get is a single fairly long activity LED blink, and that's it.
deleted
We're more than a few steps away from running Mathematica on DSLR ...
so what are the options here? I`m just about to buy a new camera...should I stick to my t2i for a while? :)
EOS M1
Insert card, close door, autostart(!?) yields a stuck loader...
(https://i.imgur.com/BA35k4T.jpg)
Pull the battery, close the door, autostart(!?) yields a success...
(https://i.imgur.com/UqGUKoz.jpg)
Pressing the power button while stuck ( normal or not ) yields a blinking green light only.
Is it normal to autostart like this on door close?
Quote from: Licaon_Kter on April 02, 2015, 11:45:39 AMIs it normal to autostart like this on door close?
Yep, see link in first post.
http://www.magiclantern.fm/forum/index.php?topic=14732
This is an April fool joke, right :D
Come on, april the 1st, Alex tells us he managed to run Linux and FreeDOS on a Canon DSLR :P
about the "calibrating delay loop..." hang:
i wasnt able to make the interrupt stable enough. its a bit hackish too.
so sometimes it doesnt get the timer interrupt, or looses it and it wont fire again.
working on that.
card door:
yeah when the door is closed, the digic ALWAYS boots. canon original firmware then asks the MPU if the power switch is ON.
we are working on MPU communication ;)
BR,
g3gg0
Another 550d, but better quality ;)
(http://i.imgur.com/Y302YS7.jpg)
Quote from: a1ex on April 02, 2015, 07:59:17 AM
And you get no display at all with the Linux binary? Not even backlight, or just no text?
Quote from: SenorClean on April 02, 2015, 08:15:32 AM
No backlight or text - all I get is a single fairly long activity LED blink, and that's it.
Same here on 70D. Hopefully this may end up with a unified solution for ML boot process :P
What is the goal with running Linux on the Canon DSLR? Is this to lead towards completely custom firmware for the camera? or just to say my camera can run Linux? I just wondering if there is going to be a real useful reason to have Linux on the camera.
Can someone explain me with runing linux on camera what features will be added?
ML is hacking it's way around Canon's code running on camera. By running own kernel/operating system (and if hardware will be well understood to write drivers for all devices), ML won't need DryOS hacking anymore.
Features like raw recording or full-res silent pictures are hacks running on top of Canon's code. This way it would be possible to implement them clean way, as we will have direct access to hardware.
Also (I believe) there were some features that was possible to implement, but were not implemented if they existed in "better" camera models. By running everything Linux based, Canon won't have any rights to interfere in ML development (in theory even if they decide to work on 1dx/dc ;) ).
BTW: Is it possible to build test binary for 30D? I'd like to try on this unsupported camera, if possible :)
It seems to me that the key technology is to be able to read directly from the sensor and then process that information rather than going through Canon's OS. Experts on the Canon 5DIII's bus architecture would know if the hardware is in place to be able to address and access all of the sensor's pixels, or if Canon just put in place what it needed for the feature set it wanted to market. If the entire sensor can addressed and accessed, then for video it becomes a matter of sampling the sensor periodically (30, 60 or 120 times per second) and then processing and storing that data. The internal hardware and bus architecture will be a limiting factor at some point. Just what that point is determines what can be done.
Quote from: lourenco on April 02, 2015, 06:35:11 PM
What is the goal with running Linux on the Canon DSLR? Is this to lead towards completely custom firmware for the camera? or just to say my camera can run Linux? I just wondering if there is going to be a real useful reason to have Linux on the camera.
Does it really have to be a goal? Some people tend to forget that we are doing all this for fun.
The biggest immediate gain for us is a deeper understanding of camera internals (for now: interrupts, timers, MPU communication, bootloader routines, and portable code that runs on all cameras).
At some point, we hope to be able to intercept buttons (which requires a good understanding of MPU communication). We might be able to drive the sensor and take a picture as well, but I wouldn't bet on it (it may take anywhere between a few weeks and several years, and I wouldn't call it "the goal"). A related quest is to emulate the entire Canon firmware in QEMU (http://www.magiclantern.fm/forum/index.php?topic=2864) - again, with no immediate benefit for regular users.
MPU communication is quite useful - there have been some feature requests about changing focus or aperture during a long exposure. If there's a way to do it, that would be via MPU.
About direct sensor access: we can already do whatever we want with it from playback mode, because Canon code does not use the sensor there. No need to run a custom OS for that. But since we don't know how to drive the sensor, we have no feature that makes use of this yet.
We also hope to attract more developers to the project. By running a separate OS, the risks of soft-bricking your camera with bad code are much lower than with a user task running on top of Canon firmware. Why? because Canon code saves settings periodically, by reflashing the ROM. Since we have no MMU, a out-of-range write (or invalid pointer) and some bad luck can be enough to cause Canon code to write gibberish in their settings area. Just ask @chris_overseas what happened with his 5D3 recently.
@kitor: keep an eye on the display thread (http://www.magiclantern.fm/forum/index.php?topic=14732), I'll build a binary for that first. The display code did not work on 5D classic (also a VxWorks camera), so...
@ a1ex & g3gg0: have you tried using buildroot ( http://buildroot.uclibc.org/ ) to build a FLAT arm init+userspace?
Confirmed for 700D.
(http://sooda.dy.fi/foo/eos700dlinux1.jpg)
(http://sooda.dy.fi/foo/eos700dlinux2.jpg)
This is awesome. I want to help. I know something about Linux source (I play with it for a living) and am willing to study whatever is necessary. For plain ML code too, of course.
(yiss, this is my first actual post.)
@rbrune:
no, i tried to compile them manually. will give it a try, thanks!
had already to patch it to make it accept FLAT options. nto a good start though :)
@sooda:
we need a framebuffer driver that can do 4bpp :)
i started to build a skeleton, but it didnt really work.
maybe i just didnt understand how things work at all.
(all this was a result of the last few days t.b.h, targetet for april 1st fool)
@nikfreak: were you able to compile the Linux demo from source?
If yes, can you run a "hg bisect" to see where it stopped working? The Linux demo was started from the display test demo, which worked fine on 6D and 70D.
@g3gg0: could you spare some details? I can see some fb stuff in the patch, does it do anything yet? I grepped for the memory address (0xC0F140D0) and looks like disp_direct.c puts the actual memory buffer address there, and the kernel code just passes the address to the fb driver and I'd guess it would use that directly for writing the pixel data, so a pointer indirection seems to be missing.
I'll try to apply the patch on a kernel source and build things from scratch. Buildroot is a good idea too, I've used that before successfully for a whole tiny "distro".
@a1ex: i didn't try to compile myself but will try to find out when it stopped working by compiling myself
@sooda:
the last time i tried, display stopped updating.
the bootloader sets some frame buffer address by writing it into 0xC0F140D0.
the kernel reads from that register back, but we could also pass it via commandline.
cool, good to see helpful hands :)
Ah, I misread the assignment. Now it makes sense. I'll try to dig in but first these toolchains need to be set up...
Second pic: 500D
(http://oi62.tinypic.com/2v2fbk7.jpg)
ok, i can has tools set up. verified that everything gets built by modifying the kernel's console writer into a rainbow, and added my name in the userspace tool that prints hello:
(http://sooda.dy.fi/foo/eos700dlinux3.jpg)
my phone's camera doesn't like blue though.
Since we can access the bootloader now and control what boots up on the camera, can we control WHERE it boots from? Say if I have a CF with 2 partitions and would like to be able to select which partition I boot from, is this possible now? Also, will we be able to boot from and use ex-fat formatted cards in cameras that don't originally support them (7d, 50d)?
That is awesome news! I have been wanting to use Linux on my camera for at least 3 years... I believe once a proper setup is made and people are able to develop and compile tools for this, we are going to enter a real golden age of DSLR's...
@sooda:
very nice, so you can confirm that all patches/manuals to build linux and userspace apps are correct?
now there are some things to resolve:
- build libc-based binaries using the elf2flt linker
- build busybox
- improve kernel drivers
- get rid of bootloder code after kernel booted
Hey!
I want to help development of linux for Canon DSLRs but I couldn't find the source at bitbucket (https://bitbucket.org/hudson/magic-lantern).
https://bitbucket.org/hudson/magic-lantern/src/6d860529476b37be313ea157c610e6d1033b6447/?at=linux-bootloader
HTH
@g3gg0: yes, that's right. I just used a slightly different place to store the binaries and elf2flt to test things around. And the little readme was missing the instructions for the initrd image, but the usual loop device trick worked. I also didn't need to compile binutils separately since Gentoo's crossdev did that.
I was wondering what's the strange jump-straight-to-loadaddr change in load_flat_binary() (I believe it won't help/work in the long run), and took it away to see what happens. With some debug prints in schedule(), it seems that the process starts up (or is at least put somewhere to be scheduled properly), but its instruction pointer never increments from the start address between the calls to schedule(). Not sure if there's something wrong in some low-level assembly stuff that boots processes up?
Also, I'm slightly confused about some memory addresses (and the kernel is too). Backtraces (from WARN_ON debugging, and the panic seen by all) show correct numerical addresses that can be tracked back to file/line/function name as long as CONFIG_DEBUG_INFO is set to y in .config. However, the function names in the traces are completely bogus. I believe this is because the kernel is loaded as executable-in-place (why's that? it's meant for loading from rom, afaik) into a position (0x00800000) that is smaller than the ram start (0x01000000). How is that possible or is that just a different ram mapping? And why is it done this way in the bootloader? Anyway, to help debugging, I deleted the check "if (s->addr < kernel_start_addr) return 0;" in scripts/kallsyms.c:symbol_valid() as a workaround and got the backtraces working. That sanity check is to disable loading some unnecessary symbol names to the kernel.
About buildroot, I couldn't find support for this particular cpu in its menus and also it wants to use elf binaries even if mmu support is turned off. We could try if yocto is any better out-of-the-box.
yeah, how to create an initrd was not explained because i thought: the ones who get that far, will know it :D
yeah that strange jump. i dont understand where and how the context is changing.
the registers in the struct get set up, but where now exactly those take effect, i dont know.
guess this is somewhere in scheduler, but didnt find it yet.
that the kernel is XIP was just a simplicity issue.
else the kernel had to load itself to its target position and that didnt work well.
when using zImage it showed a really weird behavior - i couldnt emulate it in my emu and on camera it simply hung.
its also not clear if zImage works for NOMMU kernels. at least i couldnt confirm that it does.
might be a different bahavior now, as maaany things in memory map changed since i tried that.
memory setup:
0x00000000 - 0x00000040 reset vectors (first canon, updated by bootloader, then linux')
0x00000100 - 0x00008000 ATAGS (parameters for kernel)
0x00008000 - 0x00008008 bootloader interface (function pointers for emulating text console, as linux has no fb driver yet)
0x00008000 void (*print_line)(uint32_t color, uint32_t scale, char *txt, uint32_t count);
0x00008004 void (*print_char)(void); /* pritns the character stored in the word at 0x00008008 */
0x00008008 uint32_t char_to_print
0x00008000 - 0x00698658 relocated bootloader (first 12 bytes get overwritten with function pointers)
0x0072D100 - 0x00800000 YUV/bitmap buffers
0x0072D100 disp_yuvbuf
0x007D5D00 disp_bmpbuf
0x00800000 - 0x01000000 linux kernel
0x01000000 - 0x10000000 via ATAGs reported RAM
at 0x01000000 - (sizeof(initrd)) the bootloader places the initrd image and reports that via ATAGs
Being readed all the post, I have no doubt about the importance of this (Linux on Canon hardware), but at the same time, with cero skills in coding and all the rest involved in the process, I have some questions (I'm sure I'm not the only one):
In practical terms, what does it mean?, Which kind of software can we have in the future? Wich kind of funcionalities can we have in our cameras?
Sorry for my ignorance... :-[
and congratulations to the developers, of course!!!! :)
Thanks for the memory map, that confirms what I've read so far. (edit: oh, and any pointers for qemu? fiddling with the memory card is slowish)
The timer/irq stuff also confuses me. What do you mean by "sometimes it doesnt get the timer interrupt, or looses it and it wont fire again"? I'd like to get a stable led blinker and a proper clock at least for the kernel log... About the irq lookup failure comment in the code, I'm not sure if you first need to register irq numbers to specific handlers and stuff in order to work with that. I've only worked with slightly higher-level irqs before, so not sure about that before actually looking around the code.
About the general questions on what is possible: At first, this is obviously just playing around for fun to see how far we can go. There is this joke that you can easily ping localhost (i.e. have working network stack just inside the box) but not actually do anything meaningful (such as take pics, or talk with the outer world) on stuff that you install Linux on. I believe it would be easier to write modules as just userspace processes that would use drivers written into the kernel, with proper multiprocessing, maybe even a windowing system. How easy would that be for the end-user without a mouse is another question. With the original firmware missing, we obviously have full control of the hardware, but we'd still need to know how exactly to control it. With "normal" ML, we can jump into the original firmware to take photos and all that, but the firmware probably assumes that its own operating system is running, so any of this cannot be done from Linux.
I also wonder how not having an mmu (memory management unit, providing virtual addresses) affects the userspace. At least any kind of memory protection is not there, as all pointers represent physical memory, and all processes can poke around other processes' memory even if they just get pointers wrong. Less controlled application crashing, more memory corruption. And forking (duplicating processes) is done in some strange way. Linux was not really designed for mmu-less processors, but nowadays it still works kind of well, with certain restrictions.
One of the best things is that compiling stuff for Linux is kind of easy whatever the hardware is, and all the interfaces are well documented. But as the hw is different, you can't just take gimp built for a desktop pc and copy it to the memory card and expect it to work at all. (ML's module system is good already, though.)
Python or some other scripting language would also be interesting to get working asap as a proof-of-concept, as it wouldn't need cross-compiling (binary libs for it are a different thing). Of course, it's possible to run that also without Linux directly, but anyway.
i didnt try it in qemu. couldnt get it compile on windows and had to run the emulator in a virtual machine.
so ive re-used my own ARM emulator and tried to getting it running there.
btw, i updated the memory map, as the autoexec.bin gets relocated to 0x8000 during startup.
wanted to have it in cacheable RAM and in a place where the linux kernel has no access.
about the other points, you are absolutely right.
linux was not designed for MMU-less systems. its more or less dirty, as linux doesnt even use
the MPU to protect binaries against each other to catch the situation you described.
yeah, its a proof of concept.
but i really think about post processing stuff happening on the camera.
just to test how e.g. dual iso pictures come out etc.
I am speechless. You guys are gods among men. Thank you, I'll be going to paypal to donate soon. I hope other people do the same, it's the only way developers can measure support.
My question that I didn't see posted anywhere.
Is this a piggy-back like ML is now, or is it loading without original Canon firmware?
Also, will we see custom scripts that could gain more accesses, harnessing more power from the hardware?
Thanks again.
Something to consider is if you get this over to the crazy android developers that hang out at XDA they may help build an android build for your canon. that would be something, as there is a great deal of fascinating things you can do with the camera from there.
Rules on 50D
https://www.flickr.com/photos/a_costa/17032033621/ (https://www.flickr.com/photos/a_costa/17032033621/)
Quote from: a1ex
@nikfreak: were you able to compile the Linux demo from source?
If yes, can you run a "hg bisect" to see where it stopped working? The Linux demo was started from the display test demo, which worked fine on 6D and 70D.
Just compiled the recovery branch which created a 90kb autoexec for me. That behaves the same on 70D as the one from display test (http://www.magiclantern.fm/forum/index.php?topic=14732.0) but showing me additionally "boot file i/o stubs incorrect". Retried again the big autoexec from 1st post but i can't boot it. lcd stays black. Just a 1 sec led light up after closing sdcard door.
@buildroot:
http://buildroot-busybox.2317881.n4.nabble.com/Best-way-of-building-for-unknown-architecture-td30768.html
getting exact that error after patching some stuff that enables NOMMU / FLAT support.
trying to figurie out where it comes from... :(
edit:
wow, seems i got a bit further in building the toolchains.
just a few hours, handfull of patches and modified default configs later, it builds all the standard tools for the initrd...
..still building, so no idea if the output is usable at all :)
oh and if someone wants to support, still missing:
- bzImage
- compressed initrd
I was going to suggest netBSD maybe being more appropriate, but it doesn't run MMUless either.
And for the record, plan9 doesn't seem to either :P
Is it possible to run custom OS for ARM like Arduino or Raspberry Pi? That used for drone controller.
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.
@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.
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).
@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.
Quote from: a1ex 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.
ofc! will keep you informed.
Hi, do you think this hack will allows us to run the same software on EOS DSLR than in Axiom cameras from Apertus (https://www.apertus.org/axiom), 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? ???
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.
Ok, but at least, this is fun! (5DM3 here)
(http://dl.illwieckz.net/r/Kelehe5r/20150406-190205-001.linux-sur-eos-5dm3.thomas-debesse.720.jpg) (http://dl.illwieckz.net/r/Kelehe5r/20150406-190205-001.linux-sur-eos-5dm3.thomas-debesse.jpg)
i want quake on my canon 50D ! :D
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.
Test on 1100D with the build from the first post.
"deleted"
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.
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...
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:
--- 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)
(http://sooda.dy.fi/foo/eos700dlinux-sched.jpg)
(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.
@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?)
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.
Our Linux port now runs under QEMU as well :)
(http://a1ex.magiclantern.fm/bleeding-edge/qemu-boot-linux.png)
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)
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.
as linux kernel itself now contains the -nommu patches from uClinux, we already use that.
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.
i have also some changes to qemu, so it emulates the real hardware better. (i hope ;) )
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.
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?
On the road atm.
Yeah decompressor is working fine. Kernel is at the correct position and booting fine.
I think its related to config_dram_base which I set to the whole memory.
g3gg0: I realized this later, after making my post. That's where my knowledge plateaus.
mine too :D
okay thats the MPU set up i use:
void setup_mpu(void)
{
asm(
/* 0: basic setup: 4 GiB of addressable memory */
"MOV R0, #0x0000003F\n"
"MCR p15, 0, R0, c6, c0, 0\n"
/* 1: flash: 16 MiB of addressable flash memory */
"MOV R0, #0xF8000000\n"
"ORR R0, #0x0000002F\n"
"MCR p15, 0, R0, c6, c1, 0\n"
/* 2: I/O: 512 MiB of memory mapped IO devices */
"MOV R0, #0xC0000000\n"
"ORR R0, #0x00000039\n"
"MCR p15, 0, R0, c6, c2, 0\n"
/* 3: uncached RAM: 1 GiB of addressable memory */
"MOV R0, #0x40000000\n"
"ORR R0, #0x0000003B\n"
"MCR p15, 0, R0, c6, c3, 0\n"
/* disable 4-7 */
"MOV R0, #0x00\n"
"MCR p15, 0, R0, c6, c4, 0\n"
"MCR p15, 0, R0, c6, c5, 0\n"
"MCR p15, 0, R0, c6, c6, 0\n"
"MCR p15, 0, R0, c6, c7, 0\n"
/* cacheable/bufferable bits: enable 0 and 1, disable others */
"MOV R0, #0x03\n"
"MCR p15, 0, R0, c2, c0, 0\n"
"MCR p15, 0, R0, c2, c0, 1\n"
"MCR p15, 0, R0, c3, c0, 0\n"
/* access permissions: allow all */
"MOV R0, #0x33\n"
"ORR R0, R0, LSL#0x08\n"
"ORR R0, R0, LSL#0x10\n"
"MCR p15, 0, R0, c5, c0, 2\n"
"MCR p15, 0, R0, c5, c0, 3\n"
/* enable MPU */
"MRC p15, 0, R0, c1, c0, 0\n"
"ORR R0, R0, #1\n"
"MCR p15, 0, R0, c1, c0, 0\n"
: : : "r0"
);
}
basically i had to add it to
- loader
- uncompressor
- linux kernel
still the same problem with start_task ending up at PABT exception in qemu as you reported.
weird, i cannot even breakpoint when reaching it (i am using IDA and qemu's GDB interface)
Well anyways, I'm quite thrilled by the prospects of this newfound kernel booting stuff. I don't think anyone can predict just how it'll impact ML over the next few years, but I'm thinking it'll be for the better.
Link to download from first post does not work. Nslookup says that upload.g3gg0.de does not exist in dns (g3gg0.de does)
Link to download from first post does not work.g3gg0.de how make a build
Anyone still working on this?
Had to post here to receive notifications (can't find the subscribe button).
I'm hoping to get started on this soon. Might need to find another camera to test on though, as my existing equipment is used for commercial work, and I can't afford to have anything "bricked" - even temporarily!
Getting other OS (kernel) on DSLR is a quite an achievement - congratulations!
Linux kernel seems to be rather optimal for servers. I am looking at other kernels that optimized for ARM CPUs.
1. STlinux.com - I am going to try it on my autonomous robot which controls telescope DIY AZ mount. By the way currently the system is simple round robin event driven scheduler on ARM328p.
2. minix3.org - it has been around for many years, now is minix3. I used it in 1990s for OEM controller development
3. http://www.oberon.ethz.ch - amazing OS. Very small kernel for diskless workstations. In 1980s, when it was devised, I build machine running on 6809 CPU, do not know what my employer at that time did with it ????
4. Nokia's SYMBIAN - not sure if source or specification is available, The most efficient/fastest embedded OS ever developed. Nokia development team is very friendly, so something may be negotiated???? ( I am not talking about Microsoft )
It is just food for thought .... Not sure which way I will go yet for my EOS-M as astro cam.
Hi team
So not sure how development of Linux on canon dslr's is going but one huge problem at the moment must be any sort of IO .. Even keyboard input must be currently impossible and this I guess makes debugging tricky ?
One possible way to let IO would be to use a wifi card like so :
http://hackaday.com/2015/08/15/hacking-an-sd-slot-for-wifi/
You could then remotely save files onto the card, and the OS could check for changes and run the issues commands ? A possibility at least
Looking forward to what Linux on a dslr can eventually do !
J